6 ms·

The general joke about Perl is that it's "write-only". When I wrote POPFile I spent a lot of time ensuring that the code was readable and maintainable. I hope i

The general joke about Perl is that it's "write-only". When I wrote POPFile I spent a lot of time ensuring that the code was readable and maintainable. I hope it's still understandable: https://github.com/jgrahamc/popfile/blob/trunk/engine/Classifier/Bayes.pm https://github.com/jgrahamc/popfile/blob/trunk/engine/Classi...

izietto 3y ago
Personally, I find it very readable. My only criticism is that its syntax looks "weird" nowadays. I mean, a newborn language would never go with `my` as local variables declaration prefix, or `->` for object method call, or `sub` for function declaration. I think Perl would benefit of a transpiling approach, like what Elixir is to Erlang.
- zimpenfish 3y ago
  > Personally, I find it very readable. A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".
  - motogpjimbo 3y ago
    The mistake was to think Perl was suitable for those types of applications in the first place. Perl was designed for writing small scripts to glue C programs together in a more convenient way than using shell scripts and AWK. A lot of its idiosyncratic design decisions make sense in that context. But when Perl advocates starting pushing it for writing large applications with OOP (with, of course, multiple competing object systems) it was the beginning of the end. Add in the vapourware that was Perl 6 and it was game over.
  - jlokier 3y ago
    > A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure). I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything. Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.
    - zimpenfish 3y ago
      > I think it's the culture in which those large projects were developed. Definitely you can keep your Perl under control with a strict(ish) culture but that tends to be the kind of culture Perl acolytes traditionally chafe against. I do somewhat blame the "there's more than one way to do it" Perl culture - that definitely encourages a, uh, "cowboy" approach to development that I've seen a lot in Perl houses (compared with, e.g., the Go houses that I now deal with because Go has a definite "one way to do it" culture.) But yeah, pretty much any language can be twisted into a monstrosity if you let the devs run wild.
  - Solvency 3y ago
    I'll never understand this Perl readability sentiment. Any time I've ever tried to look into <insert random open source C project>, I typically find the most esoteric and tersely named functions inhumanly imaginable. Variables like gt, pn, r8, _on, etc. I mean terse to a point of cruelty. And yet these projects often have hundreds of contributors who are happy to gloss over said unreadability, or at least forgive it more than Perl.
    - autoexec 3y ago
      You can write unreadable code in any language, and I also find complaints about about perl being unreadable unfair, but I have to admit that it does give you so much freedom that it's easier to end up with poorly written code than it is in some other languages. When I need to throw something quick and dirty together I love that freedom, but you do have to apply some self-discipline when you move to something more complex since it isn't imposed on you all the time.
    - WesolyKubeczek 3y ago
      It may happen when one directly translates into code an algorithm, a concept, or a formula from mathematics, physics, or computer science theory, where all the symbols are terse, you're supposed to have read a hefty book or stack of papers where those are introduced, and the author laments the demise of APL with all the nifty symbols it had. Oh, and you're fully expected to speak their argot fluently, of course, otherwise you're a castaway to be thrown stones at.
  - simcop2387 3y ago
    ... You worked with POOF too? https://metacpan.org/pod/POOF https://metacpan.org/pod/POOF Maintaining that in house codebase that used it was such a pain. I had to help keep that ORM up to date with the new data models after the acquisition.
    - zimpenfish 3y ago
      Nope, not POOF. From what I can see, it didn't make it to CPAN because it was entirely in-house work (and/or was too horrible even for there.)
- no_wizard 3y ago
  This is I think in large part that Larry Wall[0] is a linguist and I think this influenced both Perl and its descendant Raku[1]. Thats why it has this almost natural-ish looking syntax in alot of ways, and relies on symbolism. I also think this is why Perl is legendary for regular expressions [0]: https://en.wikipedia.org/wiki/Larry_Wall https://en.wikipedia.org/wiki/Larry_Wall [1]: https://www.raku.org/ https://www.raku.org/
  - nerdponx 3y ago
    Ironically these features make Perl feel very far from natural language, much moreso than other programming languages, even some symbol-heavy ones like Java. It feels more like IPA pronunciation notation than anything naturally derived. Raku I can't speak for because I haven't used it beyond "hello world", but it has a huge pile of symbolic infix operators in the standard library and that makes me squirm, because it's probably my most-disliked Haskell feature and IMO a substantial design mistake.
    - ilyt 3y ago
      I dislike same thing in Rust and it is much worse on that.
- masswerk 3y ago
  Bit of nitpicking: This is, because `my` doesn't declare a local variable (you do this with `local`), but a lexically private variable, which is something different. Expressing that something "belongs" to a private scope by `my` isn't much weirder than, say, referring to an object in its own context as `me`, as seen in HyperTalk.
greyman 3y ago
It's not a joke, it's true. Your code is nice, but the problem is, that Perl doesn't enforce any kind of readability; some other languages also don't but Perl is worst in this aspect, and that makes it unusable for anything bigger. New programmer will not understand the code or his colleague at the first glance, and at least in corporate environment, there are always new and junior programmers.
- calvinmorrison 3y ago
  the issue is Perl made TMTOWTDI a core value. So there's a hundred ways to express something differently. Compactly, verbosely, etc. Until you're familiar with your peers code, it can be a pain. Once you understand the style adopted internally it's not so bad. Compare that to PHP where theres generally one way to do something right.
  - throwaway173738 3y ago
    It’s even worse because not only is there more than one way, each way gets added and then deprecated, or worse there’s some big caveat like not being compatible with references or with values. This leads to all kinds of insane syntax that won’t make sense without a very careful reading. And because everything changes meaning depending on where it is, what functions were last called, and what it is being applied to there is no way to be sure of the effect of a function or a piece of syntax without having a deep amount of context from careful reading of the code before the call site. Context sensitivity sounds great in principle but leads to a lot of unpredictability in practice.
- achileas 3y ago
  All this means is that teams have to enforce readability. It's not good or bad, just a different shifting of responsibilities - and this is something that you still need to do for other languages, there's just more tooling (like flake8 and black for Python). I worked on (and modernized) a distributed ETL system all in Perl some time ago, and applying the long-codified ideals of Modern Perl made it one of the cleanest codebases I've ever worked in.
- 3y ago
tyingq 3y ago
Looks readable to me. Though you had the advantage of not being forced into using Perl for really complex data structures. I love Perl, but that's the part I don't like. If you, for example, have to parse a very deeply nested piece of JSON, you're very quickly into that weak spot. Lots of crazy sigils, braces, etc...all mushed together. Worse if you're having to use refs, globs, etc.
- kqr 3y ago
  I would argue if you "have to parse a very deeply nested" data format you should have subroutines or objects with methods for that specific task, and not rely on generic language container types. What you're running into is insufficient modeling of the problem, not a deficiency unique to any language.
  - tyingq 3y ago
    But a Perl object underneath is a hash, or list, or whatever. That abstraction doesn't save you from Perl's "sigil per type" and other oddities. It maybe encapsulates it, but...
    - kqr 3y ago
      A Perl object is a reference, meaning it will only ever present itself as a scalar (using sigil $).
      - tyingq 3y ago
        To the outside yes.
rcarmo 3y ago
I wrote a _lot_ of Perl 4. Really a lot, mostly for Radiator (a RADIUS server), and then upgraded it to Perl 5, and then moved to Python. I can still _read_ Perl code (and used to read PerlMonks for the koans), but it is definitely an acquired taste when whomever wrote it decided to golf a bit to save typing or do some clever re-use.

izietto 3y ago

Personally, I find it very readable. My only criticism is that its syntax looks "weird" nowadays. I mean, a newborn language would never go with `my` as local variables declaration prefix, or `->` for object method call, or `sub` for function declaration. I think Perl would benefit of a transpiling approach, like what Elixir is to Erlang.

zimpenfish 3y ago
> Personally, I find it very readable. A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".
- motogpjimbo 3y ago
  The mistake was to think Perl was suitable for those types of applications in the first place. Perl was designed for writing small scripts to glue C programs together in a more convenient way than using shell scripts and AWK. A lot of its idiosyncratic design decisions make sense in that context. But when Perl advocates starting pushing it for writing large applications with OOP (with, of course, multiple competing object systems) it was the beginning of the end. Add in the vapourware that was Perl 6 and it was game over.
- jlokier 3y ago
  > A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure). I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything. Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.
  - zimpenfish 3y ago
    > I think it's the culture in which those large projects were developed. Definitely you can keep your Perl under control with a strict(ish) culture but that tends to be the kind of culture Perl acolytes traditionally chafe against. I do somewhat blame the "there's more than one way to do it" Perl culture - that definitely encourages a, uh, "cowboy" approach to development that I've seen a lot in Perl houses (compared with, e.g., the Go houses that I now deal with because Go has a definite "one way to do it" culture.) But yeah, pretty much any language can be twisted into a monstrosity if you let the devs run wild.
- Solvency 3y ago
  I'll never understand this Perl readability sentiment. Any time I've ever tried to look into <insert random open source C project>, I typically find the most esoteric and tersely named functions inhumanly imaginable. Variables like gt, pn, r8, _on, etc. I mean terse to a point of cruelty. And yet these projects often have hundreds of contributors who are happy to gloss over said unreadability, or at least forgive it more than Perl.
  - autoexec 3y ago
    You can write unreadable code in any language, and I also find complaints about about perl being unreadable unfair, but I have to admit that it does give you so much freedom that it's easier to end up with poorly written code than it is in some other languages. When I need to throw something quick and dirty together I love that freedom, but you do have to apply some self-discipline when you move to something more complex since it isn't imposed on you all the time.
  - WesolyKubeczek 3y ago
    It may happen when one directly translates into code an algorithm, a concept, or a formula from mathematics, physics, or computer science theory, where all the symbols are terse, you're supposed to have read a hefty book or stack of papers where those are introduced, and the author laments the demise of APL with all the nifty symbols it had. Oh, and you're fully expected to speak their argot fluently, of course, otherwise you're a castaway to be thrown stones at.
- simcop2387 3y ago
  ... You worked with POOF too? https://metacpan.org/pod/POOF https://metacpan.org/pod/POOF Maintaining that in house codebase that used it was such a pain. I had to help keep that ORM up to date with the new data models after the acquisition.
  - zimpenfish 3y ago
    Nope, not POOF. From what I can see, it didn't make it to CPAN because it was entirely in-house work (and/or was too horrible even for there.)
no_wizard 3y ago
This is I think in large part that Larry Wall[0] is a linguist and I think this influenced both Perl and its descendant Raku[1]. Thats why it has this almost natural-ish looking syntax in alot of ways, and relies on symbolism. I also think this is why Perl is legendary for regular expressions [0]: https://en.wikipedia.org/wiki/Larry_Wall https://en.wikipedia.org/wiki/Larry_Wall [1]: https://www.raku.org/ https://www.raku.org/
- nerdponx 3y ago
  Ironically these features make Perl feel very far from natural language, much moreso than other programming languages, even some symbol-heavy ones like Java. It feels more like IPA pronunciation notation than anything naturally derived. Raku I can't speak for because I haven't used it beyond "hello world", but it has a huge pile of symbolic infix operators in the standard library and that makes me squirm, because it's probably my most-disliked Haskell feature and IMO a substantial design mistake.
  - ilyt 3y ago
    I dislike same thing in Rust and it is much worse on that.
masswerk 3y ago
Bit of nitpicking: This is, because `my` doesn't declare a local variable (you do this with `local`), but a lexically private variable, which is something different. Expressing that something "belongs" to a private scope by `my` isn't much weirder than, say, referring to an object in its own context as `me`, as seen in HyperTalk.

greyman 3y ago

It's not a joke, it's true. Your code is nice, but the problem is, that Perl doesn't enforce any kind of readability; some other languages also don't but Perl is worst in this aspect, and that makes it unusable for anything bigger. New programmer will not understand the code or his colleague at the first glance, and at least in corporate environment, there are always new and junior programmers.

calvinmorrison 3y ago
the issue is Perl made TMTOWTDI a core value. So there's a hundred ways to express something differently. Compactly, verbosely, etc. Until you're familiar with your peers code, it can be a pain. Once you understand the style adopted internally it's not so bad. Compare that to PHP where theres generally one way to do something right.
- throwaway173738 3y ago
  It’s even worse because not only is there more than one way, each way gets added and then deprecated, or worse there’s some big caveat like not being compatible with references or with values. This leads to all kinds of insane syntax that won’t make sense without a very careful reading. And because everything changes meaning depending on where it is, what functions were last called, and what it is being applied to there is no way to be sure of the effect of a function or a piece of syntax without having a deep amount of context from careful reading of the code before the call site. Context sensitivity sounds great in principle but leads to a lot of unpredictability in practice.
achileas 3y ago
All this means is that teams have to enforce readability. It's not good or bad, just a different shifting of responsibilities - and this is something that you still need to do for other languages, there's just more tooling (like flake8 and black for Python). I worked on (and modernized) a distributed ETL system all in Perl some time ago, and applying the long-codified ideals of Modern Perl made it one of the cleanest codebases I've ever worked in.
3y ago

tyingq 3y ago

Looks readable to me. Though you had the advantage of not being forced into using Perl for really complex data structures. I love Perl, but that's the part I don't like. If you, for example, have to parse a very deeply nested piece of JSON, you're very quickly into that weak spot. Lots of crazy sigils, braces, etc...all mushed together. Worse if you're having to use refs, globs, etc.

kqr 3y ago
I would argue if you "have to parse a very deeply nested" data format you should have subroutines or objects with methods for that specific task, and not rely on generic language container types. What you're running into is insufficient modeling of the problem, not a deficiency unique to any language.
- tyingq 3y ago
  But a Perl object underneath is a hash, or list, or whatever. That abstraction doesn't save you from Perl's "sigil per type" and other oddities. It maybe encapsulates it, but...
  - kqr 3y ago
    A Perl object is a reference, meaning it will only ever present itself as a scalar (using sigil $).
    - tyingq 3y ago
      To the outside yes.

rcarmo 3y ago

I wrote a _lot_ of Perl 4. Really a lot, mostly for Radiator (a RADIUS server), and then upgraded it to Perl 5, and then moved to Python. I can still _read_ Perl code (and used to read PerlMonks for the koans), but it is definitely an acquired taste when whomever wrote it decided to golf a bit to save typing or do some clever re-use.