7 ms·

I'll speak up for Perl. I learntbit voluntarily in my own spare time and actually get a lot of delight out of the language. I like that it is very unrestrictive

I'll speak up for Perl. I learntbit voluntarily in my own spare time and actually get a lot of delight out of the language. I like that it is very unrestrictive. The sigils make sense when you wrap your mind around them and you miss them in other languages. It is excellent at parsing text. I wrote a static site builder using Perl along with a very rudimentary templating system (https://soft.thran.uk https://soft.thran.uk for the curious). I've also found it very convenient for any sort of data shunting I find myself doing, it can easily manipulate and convert XLS, Json, other formats I encounter in my work. I hope it doesn't go away. There's a mindset to Perl that clicks with me and just isn't present in many other languages.

ggeorgovassilis 4y ago
> it is very unrestrictive That makes collaboration hard. The freedom I have in putting my thoughts into code, uninhibited by syntax, types and conventions makes it nearly impossible for others to understand and modify my work.
- mikem170 4y ago
  The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess The perl coding team I was on made readability our #1 priority. We didn't use tricky or out of the ordinary syntax unless it was absolutely necessary (like unusual regex, etc), and in those cases we would document what was happening with comments and maybe a reference to the appropriate man page. We had a style guide, for a consistent look and feel. We paid attention to naming and commented blocks of code, so the reader would not need to run an interpreter in their head while skimming through the code. We'd seek feedback from each other. It worked out well. We had no problems reading our code. We used the flexibility and expressiveness of perl to make our code more readable. We had the freedom to tailor the code to what we were doing, instead of the other way around.
  - ggeorgovassilis 4y ago
    > The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess If one learned how to collaborate on projects which, I think, the perl language does not incentivise. (edit) > The perl coding team I was on made readability our #1 priority. I'd love to read more about that. Have you by chance documented your experience somewhere?
    - mikem170 4y ago
      > If one learned how to collaborate on projects which, I think, the perl language does not incentivise. I tend to think that things like high level documentation, organizing libraries and functions into good abstractions, comments, and naming make a bigger difference than the programming language chosen, within reason. The goal can be to make things as easy as possible for all developers as opposed to using every feature in a language. There's a bunch of developer bad habits that can make collaboration hard. The processes and standards around development seem to make a bigger difference than the choice of language. So many coders don't bother with high level documentation, comments, or decent tests, nor do they spend the time to refactor their code as they go along to clean up readability issues. So many people just don't seem to want to bother, regardless of language. Often you have to fight management for time. I've seen atrocious and unmaintainable code in many languages. > I'd love to read more about that. Have you by chance documented your experience somewhere? My experiences grew to leading a team that were automating the reporting and deployment of complex configurations on a few tens of thousands of network devices, things like routers, switches, and voip, with all kinds of functionality for reporting, auditing, deployments, dry runs, debugging, etc. Perl is well suited to parsing and manipulating complex text configurations and outputs over ssh and interfacing to other related infrastructure applications. We were able to process devices an order of magnitude faster than HPNA (java) and ansible (python). Our code was easier to read than code using these other systems, and more sustainable. We were able to handle complex projects like mpls cutovers, 802.11x and qos migrations and upgrades, etc. We'd translate complex network architecture standards to idempotent configuration management code. We also did a lot of reporting and compliance auditing. Some of it on short notice, most of it long lived. Our project scripts read like pseudo code, a mix of perl and templating. The flexibility in perl helped us focus on representing our domain space as efficiently as possible. Our customers, who might be network engineers, managers, or compliance officers, could even read their project scripts, following the business logic, in this case the network architecture standards and/or reporting/auditing specifications. Several of us were senior engineers, and there were always several junior engineers. Senior engineers tended to work on back-end library modules and more complex projects, at least getting them off the ground. Junior engineers were mostly contractors working on less complex projects. We made things easy for ourselves, tagging to-do notes by name and category in our source code. Everything was grep'able. Our processes were not in our way. Senior engineers would do code reviews, for readability, test coverage, and maintainability, usually just adding clarifying comments during a screen share and a phone call, maybe seeing a better way to arrange something, and be a second set of eyes looking for gotchas. We'd pay attention to the depth and complexity of our abstractions, try to keep user and developer documentation close to the relevant code, and have consistent naming for variables and functions. Seniors more frequently checked up on juniors. We'd discuss things as a group when need be. Customers were responsible for signing off on correct integration test outputs. I bet that well over half our bytes were comments, documentation, and tests. My email address is in my profile, if anyone is more curious.
- jlg23 4y ago
  How you use or abuse that freedom is entirely your choice.
  - runevault 4y ago
    This is true. The downside is that a couple days of not worrying about the understandability of your code can lead to a spiral that quickly gets out of control. Plus it makes expanding a dev team significantly harder since you really need people all on the same page of what readability means. Yes you can do things like coding standards, but the more free form the language the tougher such standards are. That doesn't make a language bad, but it does change when and who can get away with using it. Same as the argument that comes up every time people talk about Lisp.
    - jlg23 4y ago
      Is there any branch of engineering where "a couple days of not worrying" does not have the potential to be "lead to a spiral that quickly gets out of control"?
      - runevault 4y ago
        Languages with tooling that will yell at you if you are sloppy make it harder to get too out of hand. Part of why I've started learning rust is between the compiler and the linter I'm forced to ask if I'm being sloppy or not.
  - AtlasBarfed 4y ago
    The languages that truly let you do anything you want flexibly invariably lead to incomprehensible ivory towers. It is why managers hate Lisp, it's why Perl is joked as write-once read-never. The issue with the "DSL" is the third letter in the abbreviation: LANGUAGE. A language isn't just a specification of syntax. A language is a collective shared understanding between a sufficiently large number of people. Without that, it is a dead language. Socially in programming, programming languages need to align to real-world concepts, because that is what enables the language to be understood by new adopters. And converging on those shared meanings is hard, because designers and lingo makers can't anticipate all the variations of understanding people will have. Learning a language is hard. So every DSL I've encountered invariably forces me to be the compiler: what is this being translated into language-wise and what does it convert to. That is a big load, so your DSL better provide power and convenience to deserve it. DSLs also run headlong into NIH/creator's advantage. The people/person that make the DSL and implement it will know it FAR better than any adopter will. And documentation is always lacking. So what is blindingly obvious to the core practitioners is very much not so to the noob. You are limited by the average intelligence of the programmer at a cultural level. The lone mad scientist may produce amazing ideas, but all the groundbreaking technology happens because an army of people can be coordinated to implement something. Lisp is basically a DSL factory, and everything is done via DSL. Can Perl7 do that better than Lisp? Is that a good or bad thing? Well, it doesn't matter. Perl5 is what it is. Perl6 was a social failure. I doubt Perl7 will change anything.
- papito 4y ago
  Writing in code is the same as writing in your native language. You are NOT writing it for the machine - you are writing it for the others like you. You are telling a story, and yes, it's hard.
- cestith 4y ago
  Teams do have conventions. There's code review. There are linters and pretty printers. There's even a standard set of default linter rules in perlcritic, taken mostly from Damian Conway's Perl Best Practices. Perl has no problem from flexibility not shared by C, Common Lisp, JavaScript, Ruby, or Ada.
dinom 4y ago
I wouldn't worry much... the reports of Perl's death have been greatly exaggerated! The blog post seems to indicate that the steering council simply wants to to avoid being bitten by Zawinski's "CADT" model. And who could blame them after seeing the kind of stunts pulled in other language communities?
- tialaramex 4y ago
  CADT (the "Cascade of Attention Deficit Teenagers") is about rewrites. Jamie particularly doesn't like the habit of throwing away old bugs you didn't fix on the rationale that if they were really still a problem you should take the time to install the new program that doesn't fix them and report them again... I don't think rewrites were on the map for Perl, except arguably for Raku (Perl 6 as was) and I don't think Raku's developers were intending to throw away bug reports and just begin over next year, indeed even though Perl 6 failed in its original goals Raku seems to still be going. I wouldn't classify any of the spectrum of language evolution strategies for popular languages as CADT, even Python where Python 3 was needlessly incompatible this wasn't part of some larger plan it just fell out from what they wanted to do and was then mismanaged. Getting to a place where strings aren't just "some bytes, who knows if they're human text, good luck" is difficult enough to justify a lot of pain on the route there, notice how C++ has tried and failed several times already. Jamie was thinking mostly of things like GNOME where this was (is?) a big problem.
  - dinom 4y ago
    When speaking colloquially, making a distincntion between a "rewrite" and a "language evolution strategy" sounds like nit-picking to me.
    - tialaramex 4y ago
      Sure, Jamie is concerned about the practical consequences. If your response to Jamie's 2019 bug report about X in WordCount was to close the ticket because you rewrote WordCount as WordCounter even though you've got no reason to think that might fix X, that's CADT. You are wasting his time. Don't use a "bug tracker" this way just write "This is broken garbage, I don't care" so that people know what's up. I don't see that nonsense with the programming languages. Even something egregious like provenance. There's a problem, neither C nor C++ make any actual sense on a vaguely modern computer as described if pointers are just machine addresses. So the compilers invented "pointer provenance" to explain why what they actually do is reasonable - but no such fix is actually endorsed in the Standards. A defect report was raised in, I think, 2003. But it was never repaired. Nobody is under the impression that C++ 11 magically means this doesn't count, they didn't fix the problem, it's still there, and in C++ 14 and C++ 17 and C++ 20. It's even there retrospectively (this seems to be controversial for some reason but it's obviously true) in C89 we just didn't realise. Under CADT the C++ committee would say, well, C++ 20 is new, you need to write a new defect report if you claim it's still broken. But they don't suffer CADT, their problems are altogether different.
api 4y ago
> It is excellent at parsing text. "Pathologically Eclectic Rubbish Lister" was one acronym I remember.
paulryanrogers 4y ago
XLSX or XLS?
- HeckFeck 4y ago
  Hah, the former. My work isn't that arcane; I've a habit of saying XLS when I mean all things Excel. But there are compatible CPAN modules for either format!
brightball 4y ago
I worked on a site conversion of a 14 year old Perl site about a decade ago. The creator had build a database out of the file system leveraging Perl's parsing capabilities. Still one of the fastest sites I've ever touched in my career but the code was really hard to follow. I find that the ideal place for Perl (for me) is smaller one-offs. When used for a huge site it can get really messy.
- petre 4y ago
  Not if you use Mojolicious and are the tidy type.
  - brightball 4y ago
    This particular project was a mess of global variables being modified in functions called across dozens of files.
fullstackchris 4y ago
I used Perl in gradschool and it still has a special place in my heart. You're right: for reading / writing files it is excellent, and I've never seen a faster tool for those tasks either (okay, unless you want to write in C )
synu 4y ago
It was the first language I learned, and I will always have a fondness for it. But I’m also happy to be using languages like Ruby now for scripting.
jamal-kumar 4y ago
A couple of the things that perl has over python and ruby... #1 is execution overhead, although that may have changed in recent times. #2 is that it's preinstalled on most linux/BSD OS's as a requirement for its plumbing, which makes it nice if you're trying to run a system on minimal dependencies. It's ugly for all the reasons that people complain about it for but those are largely complaints and the rest of us have work to get done. Oh yeah, and if you liked perl - I highly recommend learning AWK/SED. Even lower on the execution overhead (Can do shit in the processor cache and avoid memory allocation bottlenecks on enormous hundreds of gigabyte CSV datasets with a crappy processor in milliseconds kind of stuff)
- heresie-dabord 4y ago
  Perl is excellent for data analysis in a terminal. It is built to work with pipes, it's fast, concise, stable, and easy to extend. The REGEX integration is superb. It seems to me that we have a couple of generations of programmers who turn up their nose at anything that isn't Python notation and then repeat vague arguments about Python's superiority. But like all dogmatic systems, there is no agreement among the zealots. Python is far from perfect; I see many problems in the Python ecosystem. There remains much to be said for concision and expressivity in other languages. In any case, by the time one has written enough Python, one sees that the "purity of notation" is a myth. And the DSLs within Python (Pandas, Numpy) offer their own pain. awk, sed, grep, C, C++, Java, and Perl are excellent tools.
  - jamal-kumar 4y ago
    Python wins out the popularity contest because of ease of readability that I think we can take for granted. Perl is true wizardry, I mean 'sigils' and stuff you need to know in order to make it work... Plenty harder to get at first glance for sure but it's truly occult in a lot of ways. I think that's kind of cool. The way I see it is that you can do interesting things in pretty much every computer language written out there, it's just some are more arcane than others in some ways than others. I remember when python started getting big and all the old perl heads were complaining about the forced indentation hahahaha
deleted 4y ago
[deleted]

ggeorgovassilis 4y ago

> it is very unrestrictive That makes collaboration hard. The freedom I have in putting my thoughts into code, uninhibited by syntax, types and conventions makes it nearly impossible for others to understand and modify my work.

mikem170 4y ago
The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess The perl coding team I was on made readability our #1 priority. We didn't use tricky or out of the ordinary syntax unless it was absolutely necessary (like unusual regex, etc), and in those cases we would document what was happening with comments and maybe a reference to the appropriate man page. We had a style guide, for a consistent look and feel. We paid attention to naming and commented blocks of code, so the reader would not need to run an interpreter in their head while skimming through the code. We'd seek feedback from each other. It worked out well. We had no problems reading our code. We used the flexibility and expressiveness of perl to make our code more readable. We had the freedom to tailor the code to what we were doing, instead of the other way around.
- ggeorgovassilis 4y ago
  > The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess If one learned how to collaborate on projects which, I think, the perl language does not incentivise. (edit) > The perl coding team I was on made readability our #1 priority. I'd love to read more about that. Have you by chance documented your experience somewhere?
  - mikem170 4y ago
    > If one learned how to collaborate on projects which, I think, the perl language does not incentivise. I tend to think that things like high level documentation, organizing libraries and functions into good abstractions, comments, and naming make a bigger difference than the programming language chosen, within reason. The goal can be to make things as easy as possible for all developers as opposed to using every feature in a language. There's a bunch of developer bad habits that can make collaboration hard. The processes and standards around development seem to make a bigger difference than the choice of language. So many coders don't bother with high level documentation, comments, or decent tests, nor do they spend the time to refactor their code as they go along to clean up readability issues. So many people just don't seem to want to bother, regardless of language. Often you have to fight management for time. I've seen atrocious and unmaintainable code in many languages. > I'd love to read more about that. Have you by chance documented your experience somewhere? My experiences grew to leading a team that were automating the reporting and deployment of complex configurations on a few tens of thousands of network devices, things like routers, switches, and voip, with all kinds of functionality for reporting, auditing, deployments, dry runs, debugging, etc. Perl is well suited to parsing and manipulating complex text configurations and outputs over ssh and interfacing to other related infrastructure applications. We were able to process devices an order of magnitude faster than HPNA (java) and ansible (python). Our code was easier to read than code using these other systems, and more sustainable. We were able to handle complex projects like mpls cutovers, 802.11x and qos migrations and upgrades, etc. We'd translate complex network architecture standards to idempotent configuration management code. We also did a lot of reporting and compliance auditing. Some of it on short notice, most of it long lived. Our project scripts read like pseudo code, a mix of perl and templating. The flexibility in perl helped us focus on representing our domain space as efficiently as possible. Our customers, who might be network engineers, managers, or compliance officers, could even read their project scripts, following the business logic, in this case the network architecture standards and/or reporting/auditing specifications. Several of us were senior engineers, and there were always several junior engineers. Senior engineers tended to work on back-end library modules and more complex projects, at least getting them off the ground. Junior engineers were mostly contractors working on less complex projects. We made things easy for ourselves, tagging to-do notes by name and category in our source code. Everything was grep'able. Our processes were not in our way. Senior engineers would do code reviews, for readability, test coverage, and maintainability, usually just adding clarifying comments during a screen share and a phone call, maybe seeing a better way to arrange something, and be a second set of eyes looking for gotchas. We'd pay attention to the depth and complexity of our abstractions, try to keep user and developer documentation close to the relevant code, and have consistent naming for variables and functions. Seniors more frequently checked up on juniors. We'd discuss things as a group when need be. Customers were responsible for signing off on correct integration test outputs. I bet that well over half our bytes were comments, documentation, and tests. My email address is in my profile, if anyone is more curious.
jlg23 4y ago
How you use or abuse that freedom is entirely your choice.
- runevault 4y ago
  This is true. The downside is that a couple days of not worrying about the understandability of your code can lead to a spiral that quickly gets out of control. Plus it makes expanding a dev team significantly harder since you really need people all on the same page of what readability means. Yes you can do things like coding standards, but the more free form the language the tougher such standards are. That doesn't make a language bad, but it does change when and who can get away with using it. Same as the argument that comes up every time people talk about Lisp.
  - jlg23 4y ago
    Is there any branch of engineering where "a couple days of not worrying" does not have the potential to be "lead to a spiral that quickly gets out of control"?
    - runevault 4y ago
      Languages with tooling that will yell at you if you are sloppy make it harder to get too out of hand. Part of why I've started learning rust is between the compiler and the linter I'm forced to ask if I'm being sloppy or not.
- AtlasBarfed 4y ago
  The languages that truly let you do anything you want flexibly invariably lead to incomprehensible ivory towers. It is why managers hate Lisp, it's why Perl is joked as write-once read-never. The issue with the "DSL" is the third letter in the abbreviation: LANGUAGE. A language isn't just a specification of syntax. A language is a collective shared understanding between a sufficiently large number of people. Without that, it is a dead language. Socially in programming, programming languages need to align to real-world concepts, because that is what enables the language to be understood by new adopters. And converging on those shared meanings is hard, because designers and lingo makers can't anticipate all the variations of understanding people will have. Learning a language is hard. So every DSL I've encountered invariably forces me to be the compiler: what is this being translated into language-wise and what does it convert to. That is a big load, so your DSL better provide power and convenience to deserve it. DSLs also run headlong into NIH/creator's advantage. The people/person that make the DSL and implement it will know it FAR better than any adopter will. And documentation is always lacking. So what is blindingly obvious to the core practitioners is very much not so to the noob. You are limited by the average intelligence of the programmer at a cultural level. The lone mad scientist may produce amazing ideas, but all the groundbreaking technology happens because an army of people can be coordinated to implement something. Lisp is basically a DSL factory, and everything is done via DSL. Can Perl7 do that better than Lisp? Is that a good or bad thing? Well, it doesn't matter. Perl5 is what it is. Perl6 was a social failure. I doubt Perl7 will change anything.
papito 4y ago
Writing in code is the same as writing in your native language. You are NOT writing it for the machine - you are writing it for the others like you. You are telling a story, and yes, it's hard.
cestith 4y ago
Teams do have conventions. There's code review. There are linters and pretty printers. There's even a standard set of default linter rules in perlcritic, taken mostly from Damian Conway's Perl Best Practices. Perl has no problem from flexibility not shared by C, Common Lisp, JavaScript, Ruby, or Ada.

dinom 4y ago

I wouldn't worry much... the reports of Perl's death have been greatly exaggerated! The blog post seems to indicate that the steering council simply wants to to avoid being bitten by Zawinski's "CADT" model. And who could blame them after seeing the kind of stunts pulled in other language communities?

tialaramex 4y ago
CADT (the "Cascade of Attention Deficit Teenagers") is about rewrites. Jamie particularly doesn't like the habit of throwing away old bugs you didn't fix on the rationale that if they were really still a problem you should take the time to install the new program that doesn't fix them and report them again... I don't think rewrites were on the map for Perl, except arguably for Raku (Perl 6 as was) and I don't think Raku's developers were intending to throw away bug reports and just begin over next year, indeed even though Perl 6 failed in its original goals Raku seems to still be going. I wouldn't classify any of the spectrum of language evolution strategies for popular languages as CADT, even Python where Python 3 was needlessly incompatible this wasn't part of some larger plan it just fell out from what they wanted to do and was then mismanaged. Getting to a place where strings aren't just "some bytes, who knows if they're human text, good luck" is difficult enough to justify a lot of pain on the route there, notice how C++ has tried and failed several times already. Jamie was thinking mostly of things like GNOME where this was (is?) a big problem.
- dinom 4y ago
  When speaking colloquially, making a distincntion between a "rewrite" and a "language evolution strategy" sounds like nit-picking to me.
  - tialaramex 4y ago
    Sure, Jamie is concerned about the practical consequences. If your response to Jamie's 2019 bug report about X in WordCount was to close the ticket because you rewrote WordCount as WordCounter even though you've got no reason to think that might fix X, that's CADT. You are wasting his time. Don't use a "bug tracker" this way just write "This is broken garbage, I don't care" so that people know what's up. I don't see that nonsense with the programming languages. Even something egregious like provenance. There's a problem, neither C nor C++ make any actual sense on a vaguely modern computer as described if pointers are just machine addresses. So the compilers invented "pointer provenance" to explain why what they actually do is reasonable - but no such fix is actually endorsed in the Standards. A defect report was raised in, I think, 2003. But it was never repaired. Nobody is under the impression that C++ 11 magically means this doesn't count, they didn't fix the problem, it's still there, and in C++ 14 and C++ 17 and C++ 20. It's even there retrospectively (this seems to be controversial for some reason but it's obviously true) in C89 we just didn't realise. Under CADT the C++ committee would say, well, C++ 20 is new, you need to write a new defect report if you claim it's still broken. But they don't suffer CADT, their problems are altogether different.

api 4y ago

> It is excellent at parsing text. "Pathologically Eclectic Rubbish Lister" was one acronym I remember.

paulryanrogers 4y ago

XLSX or XLS?

HeckFeck 4y ago
Hah, the former. My work isn't that arcane; I've a habit of saying XLS when I mean all things Excel. But there are compatible CPAN modules for either format!

brightball 4y ago

I worked on a site conversion of a 14 year old Perl site about a decade ago. The creator had build a database out of the file system leveraging Perl's parsing capabilities. Still one of the fastest sites I've ever touched in my career but the code was really hard to follow. I find that the ideal place for Perl (for me) is smaller one-offs. When used for a huge site it can get really messy.

petre 4y ago
Not if you use Mojolicious and are the tidy type.
- brightball 4y ago
  This particular project was a mess of global variables being modified in functions called across dozens of files.

fullstackchris 4y ago

I used Perl in gradschool and it still has a special place in my heart. You're right: for reading / writing files it is excellent, and I've never seen a faster tool for those tasks either (okay, unless you want to write in C )

synu 4y ago

It was the first language I learned, and I will always have a fondness for it. But I’m also happy to be using languages like Ruby now for scripting.

jamal-kumar 4y ago

A couple of the things that perl has over python and ruby... #1 is execution overhead, although that may have changed in recent times. #2 is that it's preinstalled on most linux/BSD OS's as a requirement for its plumbing, which makes it nice if you're trying to run a system on minimal dependencies. It's ugly for all the reasons that people complain about it for but those are largely complaints and the rest of us have work to get done. Oh yeah, and if you liked perl - I highly recommend learning AWK/SED. Even lower on the execution overhead (Can do shit in the processor cache and avoid memory allocation bottlenecks on enormous hundreds of gigabyte CSV datasets with a crappy processor in milliseconds kind of stuff)

heresie-dabord 4y ago
Perl is excellent for data analysis in a terminal. It is built to work with pipes, it's fast, concise, stable, and easy to extend. The REGEX integration is superb. It seems to me that we have a couple of generations of programmers who turn up their nose at anything that isn't Python notation and then repeat vague arguments about Python's superiority. But like all dogmatic systems, there is no agreement among the zealots. Python is far from perfect; I see many problems in the Python ecosystem. There remains much to be said for concision and expressivity in other languages. In any case, by the time one has written enough Python, one sees that the "purity of notation" is a myth. And the DSLs within Python (Pandas, Numpy) offer their own pain. awk, sed, grep, C, C++, Java, and Perl are excellent tools.
- jamal-kumar 4y ago
  Python wins out the popularity contest because of ease of readability that I think we can take for granted. Perl is true wizardry, I mean 'sigils' and stuff you need to know in order to make it work... Plenty harder to get at first glance for sure but it's truly occult in a lot of ways. I think that's kind of cool. The way I see it is that you can do interesting things in pretty much every computer language written out there, it's just some are more arcane than others in some ways than others. I remember when python started getting big and all the old perl heads were complaining about the forced indentation hahahaha

deleted 4y ago

[deleted]