13 ms·

When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a

When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. Perl in one stroke collapsed the programming of C, text manipulation, the capabilities of all of the Unix utilities, and data structures into one system. For anything which wasn't subsumed into the monolith of Perl, you could easy access via backticks. It was very friendly in dealing with text streams, and that's what those call-outs in those back ticks spoke. Yes, awk and sed were replaced by Perl, but more importantly, the unmaintainable nightmare that glued all of it together was wiped out.

SoftTalker 3y ago
sed and awk are still around and still used a lot especially for one-liners. Anything more than that is typically not done as much anymore, though is certainly possible.
- LinuxBender 3y ago
  sed and awk are still around and still used a lot especially for one-liners. Adding to that some popular examples are here [1][2] [1] - https://www.commandlinefu.com/commands/matching/awk/YXdr/sort-by-votes https://www.commandlinefu.com/commands/matching/awk/YXdr/sor... [2] - https://www.commandlinefu.com/commands/matching/sed/c2Vk/sort-by-votes https://www.commandlinefu.com/commands/matching/sed/c2Vk/sor...
imron 3y ago
> Yes, awk and sed were replaced by Perl, I still use awk and sed semi regularly. I haven’t used Perl in over a decade.
- idlewords 3y ago
  Sounds like you were also replaced by Perl.
- natch 3y ago
  …that you’re aware of.
- eigenvalue 3y ago
  Agreed. I would turn to Python for anything more involved that couldn’t be done very directly and efficiently using awk/sed. I would never use Perl for anything.
  - kdmccormick 3y ago
    Same, but if there were no Python/Ruby/etc, I would probably be reaching for Perl quite a lot.
- kristopolous 3y ago
  1980s awk and sed aren't the same as the 2020s version. They've become much more useful because of the influence of things like perl. To see what I mean, here's SunOS 4.1.1's man page for awk and sed as grabbed from https://github.com/ambiamber/Run-Sun3-SunOS-4.1.1/blob/main/sunos411/sun3_manual.tar.Z https://github.com/ambiamber/Run-Sun3-SunOS-4.1.1/blob/main/... and ran through groffer(1) . These are from 1989 and 1987 respectively. The core stuff is there but not much else. https://9ol.es/sed.1v.pdf https://9ol.es/sed.1v.pdf https://9ol.es/awk.1.pdf https://9ol.es/awk.1.pdf
  - tannhaeuser 3y ago
    Awk today is very much the same language it was in 1977 when it was introduced. Comparing your links with today's POSIX awk manpage doesn't yield a single thing Perl brought to awk. At best, while JavaScript syntax is even based on awk, you could say JavaScript regexpes are based on PCRE, and it wasn't clear whether use of capture groups/back references makes Perl regexpes accidentally Turing.
    - kristopolous 3y ago
      POSIX, right. POSIX sucks. POSIX anything is stuck 30 years ago. Nobody in 2023 really uses POSIX awk on some commercial UNIX like IBM AIX, they use GNU awk, that's the modern one I'm talking about https://www.gnu.org/software/gawk/manual/html_node/index.html https://www.gnu.org/software/gawk/manual/html_node/index.htm...
      - tannhaeuser 3y ago
        What are you talking about? There is no POSIX awk implementation, just a language spec and nawk AKA the one true awk. As shipped on Mac OS, whereas Debian ships mawk in addition to gawk. gawk is just much slower and unfortunately also buggy (crashes on a non-"C" locale with complex regexpes).
        kristopolous 3y ago
        Right, "the one true awk" corresponds to a book written in 1988, very explicity. https://github.com/onetrueawk/awk https://github.com/onetrueawk/awk I was incorrect about 30 years. It's actually 35. You were the one that that said POSIX awk to begin with, I was using your terms. I understand what you meant, why don't you? As far as shitting on the GMU tools, I don't think I've seen someone do that in decades, especially just referencing the bottom of the man page like that. As far as speed, I don't know how you're using these tools, but if gawk is your bottleneck and not i/o, there's probably smarter ways to do things. This is not a productive conversation. You can live life however you want and if you're happy than I'm happy. We are definitely at an impasse. I'm off to bed.
- tharne 3y ago
  > I still use awk and sed semi regularly. I haven’t used Perl in over a decade. Same. Awk and Sed are delightful little tools that have aged exceptionally well.
  - grumpyprole 3y ago
    They are also constrained languages which gives many advantages. POSIX regex will always execute in O(n), Perl "regex" are potentially exponential and can be a security risk in certain situations.
    - 2colours 3y ago
      Well, that's at least an actual argument, even though POSIX regex would have never proven so useful in a variety of use cases. Other than that, I'm completely shocked that somebody would praise sed or awk in well into the 21st century. Turing-complete languages barely capable of properly solving any problem that has any sort of algorithmic complexity, let alone one that requires proper data types, variables or interacting with any sort of system. Really, you can do that in Perl (even in Raku) without your couple-of-liner horribly breaking down once you need some custom logic to it. Oh, and it will even resemble programming languages, not some hieroglyphs left behind by aliens.
- 2colours 3y ago
  What is the reason for that? I think they should be long gone for the lack of proper data structures, if nothing else.
_2z1p 3y ago
Not just the language itself but the whole ecosystem it brought with it was revolutionary. CPAN was incredible. There seemed like there was a module for just about anything! Perldoc and a testing framework were built right in. Regexes, backticks to shell out to the system, reporting built in. It really was the whole package.
- adastra22 3y ago
  Yeah CPAN is easy to take for granted now that every language has its own package manager (npm, cargo, pip), and even for C/C++ you can find what you want on GitHub. At the time though CPAN was revolutionary and no one else had it. To be able to just search for a module, find one that did what you wanted, then download it to your project was pure magic.
  - dhosek 3y ago
    There is some question whether CTAN (for TeX) or CPAN was the first big library. It was pretty close. I was involved tangentially with the guys in the UK who were setting up the first pass at CTAN as the administrator of the ymir.claremont.edu archive and I remember one of the things that they came up with back then was that you could do an FTP get of any directory and get back a zip archive of its contents which was pretty fancy in the 90s. That said, both CPAN and CTAN definitely show their age in that they assume a single version of dependencies will be installed on any system which causes untold nightmares when it turns out that there’s a non-backwards compatible update to something three dependencies deep that you weren’t even aware you were using.
    - sverhagen 3y ago
      >There is some question whether CTAN (for TeX) or CPAN was the first big library. I'm not in this space, but the similarity in names made me wonder if these would really have started around the same time, with an unclear "dependency order", so I reached for a search engine, and according to Wikipedia, CPAN (1993) is based on CTAN (1992).
imiric 3y ago
> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you write another small tool using your programming language of choice. Rinse and repeat. But occasionally Unix attracts users and programmers who reject this approach, and who prefer building a monolithic tool, or in the case of Larry Wall, new programming languages. To be clear, I'm a fan of Perl and think it has its place, especially in the era it came out. It inspired many modern languages, and its impact is undeniable. Personally, I find solutions you refer to as "unmaintainable nightmare" to be simple and elegant, if used correctly. No, you probably shouldn't abuse shell scripts to build a complex system, and beyond a certain level of complexity, a programming language is the better tool. But for most simple processing pipelines, Unix tools are perfectly capable and can be used to build maintainable solutions. The classic Knuth-Mcllroy bout[1] comes to mind. Would you rather maintain Knuth's solution or Mcllroy's? [1]: https://matt-rickard.com/instinct-and-culture https://matt-rickard.com/instinct-and-culture
- Scubabear68 3y ago
  I don’t think you’ve seen the kind of scripts the person you are responding to is talking about. I have, and mentioned one lower down in the comments. Unix philosophy was great but does not scale well in terms of maintainability or efficiency. Invoking processes over and over again loops is godawful slow. And the horror of complicated shell scripts is legendary.
  - imiric 3y ago
    I certainly have, and might have written a few of those myself. But this doesn't make this approach inherently wrong or obsolete. The programmer is wrong for trying to use the tools beyond their capabilities. Where that line is drawn is subjective, as is the concept of maintainability, but if you feel that you're struggling to accomplish something, and that it's becoming a chore to maintain, the path forward is choosing a more capable tool, like a programming language.
stubish 3y ago
Back in the 90s I got my first 'real' job, and needed to learn well grep, awk, sed, col et. al. Or learn Perl. Perl kept us afloat until we had too much Perl and needed to switch to Python. And I still don't know awk or sed; to this day my fingers just go with 'perl -pie'.
BirAdam 3y ago
All software eventually becomes an unmaintainable nightmare.
tannhaeuser 3y ago
Perl didn't replace anything. It was replaced by PHP for CGI programming (which says a lot!) and botched itself by the second worst version migration of all times.
- bonzini 3y ago
  Perl 4 to 5 was quite successful. Perl 5 to 6 was definitely worse than Python 2 to 3, since the latter actually worked out in the end.
asah 3y ago
Ignore the haters - they're too young to remember. I remember different CLI tools working differently on SysV and other variants. I remember AIX and HPUX. Perl meant one thing that just goddamned worked mostly the same way. That and vi and emacs. :-)
yjftsjthsd-h 3y ago
> Yes, awk and sed were replaced by Perl, but more importantly, the unmaintainable nightmare that glued all of it together was wiped out. Er, Perl replaced an unmaintainable nightmare? Perl, the language infamous for being indistinguishable from line noise?
- margalabargala 3y ago
  Yes. It's comparative. The absolute value of Perl's readability, maintainability, and general intuitiveness is massively better than all comparable tools that existed when Perl came out. Perl is a massive improvement over those tools. If you have doubts, try writing a complicated production software stack in awk. Then hand it off to a coworker. One need not be irreplaceably good, if one is already beating the current state of the art by an order of magnitude. Perl did this.
  - BaseballPhysics 3y ago
    Moreover, as often as people joke about the readability of Perl code, that's entirely a function of the developer. I've easily written tens of thousands of lines of Perl, and not a single person has complained about difficulty reading or maintaining that code. Why? Because I apply all the usual best practices for code hygiene that apply to any language. Frankly, I think most people are just repeating a meme they heard once, and the rest just get put off by a) sigils, and b) the use of implicit variables (which I tend to use only very sparingly, and mostly in quick one-liners). But a developer that poorly names their functions or variables, fails to modularize appropriately, fails to document their code, abuses language features because they want to be excessively terse or clever, that kind of person is gonna write crappy, difficult-to-maintain code no matter what language they use. In fact, I'd argue the advent and popularity of Python--which was pretty radical in how opinionated it was at the time--is a direct response to languages like Perl and C that were a lot more free-form and easier to abuse by poor coders.
    - tribby 3y ago
      absolutely a response to perl. “TOOWTDI” has been an expression in the python community for a long time :)
gm3dmo 3y ago
The dozens of different versions of UNIX did not help either. A bug in their sed grep awk toolchain meant that you had to write workarounds for things like "Sequioa Unix" to support is single customer. as long as the UNIX flavor had a PERL port all of that could go away. PERL being open source meant you were a "make" away from having the same environment on all those unixes. even today when the dozens of UNIX distributions have collapsed into a couple of Lunux flavours, getting a shell based script to work reliably between say macOS and redhat can take some effort.
zenlot 3y ago
And now you can just use PowerShell which combines it all in one cross platform scripting language.
- csydas 3y ago
  assuming that the security administrators of the systems you want to run the script on haven't followed Microsoft's 'recommendations' and basically made powershell unusable on the systems due to random GPOs ;) PS is 'okay' as a scripting language, but it's very frustrating how Microsoft's security defaults seem to be dead-set on ensuring you can't use scripts on systems without jumping through a bunch of hoops. I get how MS got to this conclusion that it needs to be locked down, but it makes me think twice about pumping out a script since I know I might need to walk my colleagues through how to actually run the damn thing depending on what the Security Admins decided to lock down that week.
- doliveira 3y ago
  Cross-platform? I guess technically it is...
slavik81 3y ago
# Sometimes I wake up screaming. Famous figures are gathered in the nightmare, # Steve Bourne, Larry Wall, the whole of the ANSI C committee. They're just # standing there, waiting, but the truely terrifying thing is what they carry # in their hands. At first sight each seems to bear the same thing, but it is # not so for the forms in their grasp are ever so slightly different one from # the other. Each is twisted in some grotesque way from the other to make each # an unspeakable perversion impossible to perceive without the onset of madness. # True insanity awaits anyone who perceives all of these horrors together. https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/recipes/boost/boost-with-bjam.inc#L94 https://github.com/openembedded/openembedded/blob/fabd8e6d07...
opan 3y ago
For me in the current day, perl is too much like "real programming", while I'm fairly comfortable with grep and sed, and to a lesser extent, awk. Piping a bunch of stuff together is just easier to understand and gradually expand. One thing I do in a lot of scripts is read from and write to the clipboard, usually transforming text with sed and co. Stuff like turning YouTube shorts URLs into regular ones, taking just the last directory name from a long file path on my clipboard, making my clipboard lowercase, etc. I barely get into loops and lists when trying to learn Python before losing interest/focus and not trying again for months. It feels very abstract and like it's not useful for day-to-day stuff without learning and writing a lot. Shell stuff is very short and powerful and feels more grounded in reality. To be clear, I am not using if/else and the like in my shell scripts either. Usually they're just a few lines with little to no logic, but they're immensely useful. I can't imagine learning perl and then using it for all this stuff.
marttt 3y ago
A single-executable perl5 (like awk, but with advanced string manipulation + sigils + timtowdy madness) would be great.
tod222 3y ago
Yes, writing shell scripts calling awk and sed was awful, just an aesthetic nightmare to work with. Properly quoting strings was always problematic, and while Usenet was available there wasn't a plethora of information like nowadays. This was a few years before Bash was released. Through my use of Usenet I learned that a better reader program was available called 'rn', which I downloaded and built. It had an amazing handwritten install script (autoconf was years off) which could automatically configure and build rn on any *NIX system. All developed by a fellow named Larry Wall. rn was truly a joy to use and made reading Usenet swift and efficient. It would get updated with the fixes that came across Usenet that I'd apply using the clever 'patch' program, also written by Larry Wall. Based on my experience with his other software, when Larry Wall released Perl on Usenet I immediately downloaded, built, and started using it. As promised, for scripting things not requiring a C program, it was massive improvement. Version 2.0 came out and brought many great new capabilities. I wasn't writing software while versions 3 and 4 came out; I started using it again after version 5 and the appearance of CPAN. Over the years I've used Perl extensively for task automation and data wrangling. Python now dominates Perl's niche because it's easier to learn and interfaces better with C. It's also less flexible, which compared to Perl is a virtue. One of Perl's mottos is TMTOWTDI—there's more than one way to do it. But many of them are bad. Much of Perl's poor reputation ("line noise") stems from this. But when Perl was released it was a revelation, like a drab day when the clouds suddenly part letting warm sunlight pour down on the land.

SoftTalker 3y ago

sed and awk are still around and still used a lot especially for one-liners. Anything more than that is typically not done as much anymore, though is certainly possible.

LinuxBender 3y ago
sed and awk are still around and still used a lot especially for one-liners. Adding to that some popular examples are here [1][2] [1] - https://www.commandlinefu.com/commands/matching/awk/YXdr/sort-by-votes https://www.commandlinefu.com/commands/matching/awk/YXdr/sor... [2] - https://www.commandlinefu.com/commands/matching/sed/c2Vk/sort-by-votes https://www.commandlinefu.com/commands/matching/sed/c2Vk/sor...

imron 3y ago

> Yes, awk and sed were replaced by Perl, I still use awk and sed semi regularly. I haven’t used Perl in over a decade.

idlewords 3y ago
Sounds like you were also replaced by Perl.
natch 3y ago
…that you’re aware of.
eigenvalue 3y ago
Agreed. I would turn to Python for anything more involved that couldn’t be done very directly and efficiently using awk/sed. I would never use Perl for anything.
- kdmccormick 3y ago
  Same, but if there were no Python/Ruby/etc, I would probably be reaching for Perl quite a lot.
kristopolous 3y ago
1980s awk and sed aren't the same as the 2020s version. They've become much more useful because of the influence of things like perl. To see what I mean, here's SunOS 4.1.1's man page for awk and sed as grabbed from https://github.com/ambiamber/Run-Sun3-SunOS-4.1.1/blob/main/sunos411/sun3_manual.tar.Z https://github.com/ambiamber/Run-Sun3-SunOS-4.1.1/blob/main/... and ran through groffer(1) . These are from 1989 and 1987 respectively. The core stuff is there but not much else. https://9ol.es/sed.1v.pdf https://9ol.es/sed.1v.pdf https://9ol.es/awk.1.pdf https://9ol.es/awk.1.pdf
- tannhaeuser 3y ago
  Awk today is very much the same language it was in 1977 when it was introduced. Comparing your links with today's POSIX awk manpage doesn't yield a single thing Perl brought to awk. At best, while JavaScript syntax is even based on awk, you could say JavaScript regexpes are based on PCRE, and it wasn't clear whether use of capture groups/back references makes Perl regexpes accidentally Turing.
  - kristopolous 3y ago
    POSIX, right. POSIX sucks. POSIX anything is stuck 30 years ago. Nobody in 2023 really uses POSIX awk on some commercial UNIX like IBM AIX, they use GNU awk, that's the modern one I'm talking about https://www.gnu.org/software/gawk/manual/html_node/index.html https://www.gnu.org/software/gawk/manual/html_node/index.htm...
    - tannhaeuser 3y ago
      What are you talking about? There is no POSIX awk implementation, just a language spec and nawk AKA the one true awk. As shipped on Mac OS, whereas Debian ships mawk in addition to gawk. gawk is just much slower and unfortunately also buggy (crashes on a non-"C" locale with complex regexpes).
      - kristopolous 3y ago
        Right, "the one true awk" corresponds to a book written in 1988, very explicity. https://github.com/onetrueawk/awk https://github.com/onetrueawk/awk I was incorrect about 30 years. It's actually 35. You were the one that that said POSIX awk to begin with, I was using your terms. I understand what you meant, why don't you? As far as shitting on the GMU tools, I don't think I've seen someone do that in decades, especially just referencing the bottom of the man page like that. As far as speed, I don't know how you're using these tools, but if gawk is your bottleneck and not i/o, there's probably smarter ways to do things. This is not a productive conversation. You can live life however you want and if you're happy than I'm happy. We are definitely at an impasse. I'm off to bed.
tharne 3y ago
> I still use awk and sed semi regularly. I haven’t used Perl in over a decade. Same. Awk and Sed are delightful little tools that have aged exceptionally well.
- grumpyprole 3y ago
  They are also constrained languages which gives many advantages. POSIX regex will always execute in O(n), Perl "regex" are potentially exponential and can be a security risk in certain situations.
  - 2colours 3y ago
    Well, that's at least an actual argument, even though POSIX regex would have never proven so useful in a variety of use cases. Other than that, I'm completely shocked that somebody would praise sed or awk in well into the 21st century. Turing-complete languages barely capable of properly solving any problem that has any sort of algorithmic complexity, let alone one that requires proper data types, variables or interacting with any sort of system. Really, you can do that in Perl (even in Raku) without your couple-of-liner horribly breaking down once you need some custom logic to it. Oh, and it will even resemble programming languages, not some hieroglyphs left behind by aliens.
2colours 3y ago
What is the reason for that? I think they should be long gone for the lack of proper data structures, if nothing else.

_2z1p 3y ago

Not just the language itself but the whole ecosystem it brought with it was revolutionary. CPAN was incredible. There seemed like there was a module for just about anything! Perldoc and a testing framework were built right in. Regexes, backticks to shell out to the system, reporting built in. It really was the whole package.

adastra22 3y ago
Yeah CPAN is easy to take for granted now that every language has its own package manager (npm, cargo, pip), and even for C/C++ you can find what you want on GitHub. At the time though CPAN was revolutionary and no one else had it. To be able to just search for a module, find one that did what you wanted, then download it to your project was pure magic.
- dhosek 3y ago
  There is some question whether CTAN (for TeX) or CPAN was the first big library. It was pretty close. I was involved tangentially with the guys in the UK who were setting up the first pass at CTAN as the administrator of the ymir.claremont.edu archive and I remember one of the things that they came up with back then was that you could do an FTP get of any directory and get back a zip archive of its contents which was pretty fancy in the 90s. That said, both CPAN and CTAN definitely show their age in that they assume a single version of dependencies will be installed on any system which causes untold nightmares when it turns out that there’s a non-backwards compatible update to something three dependencies deep that you weren’t even aware you were using.
  - sverhagen 3y ago
    >There is some question whether CTAN (for TeX) or CPAN was the first big library. I'm not in this space, but the similarity in names made me wonder if these would really have started around the same time, with an unclear "dependency order", so I reached for a search engine, and according to Wikipedia, CPAN (1993) is based on CTAN (1992).

imiric 3y ago

> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you write another small tool using your programming language of choice. Rinse and repeat. But occasionally Unix attracts users and programmers who reject this approach, and who prefer building a monolithic tool, or in the case of Larry Wall, new programming languages. To be clear, I'm a fan of Perl and think it has its place, especially in the era it came out. It inspired many modern languages, and its impact is undeniable. Personally, I find solutions you refer to as "unmaintainable nightmare" to be simple and elegant, if used correctly. No, you probably shouldn't abuse shell scripts to build a complex system, and beyond a certain level of complexity, a programming language is the better tool. But for most simple processing pipelines, Unix tools are perfectly capable and can be used to build maintainable solutions. The classic Knuth-Mcllroy bout[1] comes to mind. Would you rather maintain Knuth's solution or Mcllroy's? [1]: https://matt-rickard.com/instinct-and-culture https://matt-rickard.com/instinct-and-culture

Scubabear68 3y ago
I don’t think you’ve seen the kind of scripts the person you are responding to is talking about. I have, and mentioned one lower down in the comments. Unix philosophy was great but does not scale well in terms of maintainability or efficiency. Invoking processes over and over again loops is godawful slow. And the horror of complicated shell scripts is legendary.
- imiric 3y ago
  I certainly have, and might have written a few of those myself. But this doesn't make this approach inherently wrong or obsolete. The programmer is wrong for trying to use the tools beyond their capabilities. Where that line is drawn is subjective, as is the concept of maintainability, but if you feel that you're struggling to accomplish something, and that it's becoming a chore to maintain, the path forward is choosing a more capable tool, like a programming language.

stubish 3y ago

Back in the 90s I got my first 'real' job, and needed to learn well grep, awk, sed, col et. al. Or learn Perl. Perl kept us afloat until we had too much Perl and needed to switch to Python. And I still don't know awk or sed; to this day my fingers just go with 'perl -pie'.

BirAdam 3y ago

All software eventually becomes an unmaintainable nightmare.

tannhaeuser 3y ago

Perl didn't replace anything. It was replaced by PHP for CGI programming (which says a lot!) and botched itself by the second worst version migration of all times.

bonzini 3y ago
Perl 4 to 5 was quite successful. Perl 5 to 6 was definitely worse than Python 2 to 3, since the latter actually worked out in the end.

asah 3y ago

Ignore the haters - they're too young to remember. I remember different CLI tools working differently on SysV and other variants. I remember AIX and HPUX. Perl meant one thing that just goddamned worked mostly the same way. That and vi and emacs. :-)

yjftsjthsd-h 3y ago

> Yes, awk and sed were replaced by Perl, but more importantly, the unmaintainable nightmare that glued all of it together was wiped out. Er, Perl replaced an unmaintainable nightmare? Perl, the language infamous for being indistinguishable from line noise?

margalabargala 3y ago
Yes. It's comparative. The absolute value of Perl's readability, maintainability, and general intuitiveness is massively better than all comparable tools that existed when Perl came out. Perl is a massive improvement over those tools. If you have doubts, try writing a complicated production software stack in awk. Then hand it off to a coworker. One need not be irreplaceably good, if one is already beating the current state of the art by an order of magnitude. Perl did this.
- BaseballPhysics 3y ago
  Moreover, as often as people joke about the readability of Perl code, that's entirely a function of the developer. I've easily written tens of thousands of lines of Perl, and not a single person has complained about difficulty reading or maintaining that code. Why? Because I apply all the usual best practices for code hygiene that apply to any language. Frankly, I think most people are just repeating a meme they heard once, and the rest just get put off by a) sigils, and b) the use of implicit variables (which I tend to use only very sparingly, and mostly in quick one-liners). But a developer that poorly names their functions or variables, fails to modularize appropriately, fails to document their code, abuses language features because they want to be excessively terse or clever, that kind of person is gonna write crappy, difficult-to-maintain code no matter what language they use. In fact, I'd argue the advent and popularity of Python--which was pretty radical in how opinionated it was at the time--is a direct response to languages like Perl and C that were a lot more free-form and easier to abuse by poor coders.
  - tribby 3y ago
    absolutely a response to perl. “TOOWTDI” has been an expression in the python community for a long time :)

gm3dmo 3y ago

The dozens of different versions of UNIX did not help either. A bug in their sed grep awk toolchain meant that you had to write workarounds for things like "Sequioa Unix" to support is single customer. as long as the UNIX flavor had a PERL port all of that could go away. PERL being open source meant you were a "make" away from having the same environment on all those unixes. even today when the dozens of UNIX distributions have collapsed into a couple of Lunux flavours, getting a shell based script to work reliably between say macOS and redhat can take some effort.

zenlot 3y ago

And now you can just use PowerShell which combines it all in one cross platform scripting language.

csydas 3y ago
assuming that the security administrators of the systems you want to run the script on haven't followed Microsoft's 'recommendations' and basically made powershell unusable on the systems due to random GPOs ;) PS is 'okay' as a scripting language, but it's very frustrating how Microsoft's security defaults seem to be dead-set on ensuring you can't use scripts on systems without jumping through a bunch of hoops. I get how MS got to this conclusion that it needs to be locked down, but it makes me think twice about pumping out a script since I know I might need to walk my colleagues through how to actually run the damn thing depending on what the Security Admins decided to lock down that week.
doliveira 3y ago
Cross-platform? I guess technically it is...

slavik81 3y ago

# Sometimes I wake up screaming. Famous figures are gathered in the nightmare, # Steve Bourne, Larry Wall, the whole of the ANSI C committee. They're just # standing there, waiting, but the truely terrifying thing is what they carry # in their hands. At first sight each seems to bear the same thing, but it is # not so for the forms in their grasp are ever so slightly different one from # the other. Each is twisted in some grotesque way from the other to make each # an unspeakable perversion impossible to perceive without the onset of madness. # True insanity awaits anyone who perceives all of these horrors together. https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/recipes/boost/boost-with-bjam.inc#L94 https://github.com/openembedded/openembedded/blob/fabd8e6d07...

opan 3y ago

For me in the current day, perl is too much like "real programming", while I'm fairly comfortable with grep and sed, and to a lesser extent, awk. Piping a bunch of stuff together is just easier to understand and gradually expand. One thing I do in a lot of scripts is read from and write to the clipboard, usually transforming text with sed and co. Stuff like turning YouTube shorts URLs into regular ones, taking just the last directory name from a long file path on my clipboard, making my clipboard lowercase, etc. I barely get into loops and lists when trying to learn Python before losing interest/focus and not trying again for months. It feels very abstract and like it's not useful for day-to-day stuff without learning and writing a lot. Shell stuff is very short and powerful and feels more grounded in reality. To be clear, I am not using if/else and the like in my shell scripts either. Usually they're just a few lines with little to no logic, but they're immensely useful. I can't imagine learning perl and then using it for all this stuff.

marttt 3y ago

A single-executable perl5 (like awk, but with advanced string manipulation + sigils + timtowdy madness) would be great.

tod222 3y ago

Yes, writing shell scripts calling awk and sed was awful, just an aesthetic nightmare to work with. Properly quoting strings was always problematic, and while Usenet was available there wasn't a plethora of information like nowadays. This was a few years before Bash was released. Through my use of Usenet I learned that a better reader program was available called 'rn', which I downloaded and built. It had an amazing handwritten install script (autoconf was years off) which could automatically configure and build rn on any *NIX system. All developed by a fellow named Larry Wall. rn was truly a joy to use and made reading Usenet swift and efficient. It would get updated with the fixes that came across Usenet that I'd apply using the clever 'patch' program, also written by Larry Wall. Based on my experience with his other software, when Larry Wall released Perl on Usenet I immediately downloaded, built, and started using it. As promised, for scripting things not requiring a C program, it was massive improvement. Version 2.0 came out and brought many great new capabilities. I wasn't writing software while versions 3 and 4 came out; I started using it again after version 5 and the appearance of CPAN. Over the years I've used Perl extensively for task automation and data wrangling. Python now dominates Perl's niche because it's easier to learn and interfaces better with C. It's also less flexible, which compared to Perl is a virtue. One of Perl's mottos is TMTOWTDI—there's more than one way to do it. But many of them are bad. Much of Perl's poor reputation ("line noise") stems from this. But when Perl was released it was a revelation, like a drab day when the clouds suddenly part letting warm sunlight pour down on the land.