7 ms·

Any historical background for the reference of Perl by Torvalds?

dijit 4y ago
Perl is notorious for being "write only". As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects. I feel qualified to say such things as I've worked on a billion-line perl codebase before.
- bogeholm 4y ago
  _one billion lines of Perl_? Wow
  - School-Cotton 4y ago
    I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java. (I wouldn't be surprised if they still had sizable amounts of Perl in dark corners).
    - nkozyra 4y ago
      There's a spirograph guy in the corner, the only one left that knows perl, lurking out and trying to entice people with its merits. Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff. To be fair if I walked away from Rust for a year I'd probably be similarly lost.
      - dhosek 4y ago
        I still will reach for Perl for the occasional quick one-of text-processing application, but I do spend a lot of time in perldoc when I do.
    - Cthulhu_ 4y ago
      I can imagine corporate Java codebases can end up in the billion LOC as well. I mean it MIGHT be easier to read, or easier to find developers for... I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.
      - gautamdivgi 4y ago
        Ha ha no. Sorry to disappoint :) Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it. This isn’t an indictment of Java. Just resume driven design.
        rhacker 4y ago
        That's why I left Java 5 years (after like a 12 year career in it) ago and plan on never getting another Java job. It's just making classes have "some" kind of use no matter what the task is, there's no coding to solve problems, it's coding to make structure.
        gautamdivgi 4y ago
        To be fair, I’ve seen this in c++ as well. Building an entire structure of classes like “java” and then using “design patterns” on those abstractions. All to implement a simple 7 step socket communication protocol. It was a “wtf is going on here moment”?
        rhacker 4y ago
        I was also part of it. I did my own share of - well if we design it this way then we can have a second "type" that does X with the same interface. And it just keeps on iterating like that. It's still a useful pattern, but often at least in my own case, overused for really trivial stuff. Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.
    - VyseofArcadia 4y ago
      With Java? I usually think of Perl as a glue language, like bash scripting. Java would not be my choice to glue components together.
      - dhosek 4y ago
        Nah, Perl can be a perfectly fine applications language. Some things get kind of ugly with it (object-orientation is notoriously hacky and there are two different approaches to classes that take inverse (literally) approaches to how to represent the objects in terms of Perl’s scalars, arrays and maps. It does suffer a bit from being an early mover so there are questionable choices like the fact that library code is traditionally installed system-wide so good luck if application A needs library v3 an application B needs v2 and v2 and v3 have some subtle incompatibility, but Perl is no less capable than Python and arguably more capable than PHP, both of which have plenty of applications written in them.
      - School-Cotton 4y ago
        Perl was the primary application-layer language at Amazon. It was used for most things that didn't need to be in a low-level language for performance or other reasons (for those, C++ was used instead).
    - thesuperbigfrog 4y ago
      >> I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java. The Amazon retail website (amazon.com and related versions for various countries) used the Perl Mason templating system (https://masonbook.houseabsolute.com/ https://masonbook.houseabsolute.com/) to allow various teams to build web site components in a performant and secure way. It worked quite well since it ran quickly and isolated components so that only one small change could be made without breaking other components.
  - twic 4y ago
    Could have been worse. Could all have been on one line.
- hardware2win 4y ago
  Bilion lines? What, how? Thats bigger than windows linux llvm chromium and 5 other compilers combined according to google
  - dijit 4y ago
    Commentary on that was made at the time. Linux is a pretty small codebase compared to most proprietary codebases in large companies to be fair though.
    - angrygoat 4y ago
      Yeah, this – it's easy to forget that infrastructure code (Linux, libc, openssl, ...) really is the tip of the iceberg. Industrial codebases are often at least an order of magnitude bigger; really, that shouldn't surprise us: there are so many problems to be solved, it should be unsurprising that the specific outweighs the general.
- belter 4y ago
  Shudder in horror.... "Booking.com uses the Perl programming language heavily across its entire technical infrastructure." - https://medium.com/booking-com-development/a-faster-perl-runtime-in-tiny-steps-97a1191d75e5 https://medium.com/booking-com-development/a-faster-perl-run...
  - klabb3 4y ago
    Dad, let's go home. Please.
- LinuxBender 4y ago
  I've often found I could work around the "write only" mantra using perltidy. I pass other peoples code to perltidy with the flags that match my style, make changes, then pass it back through perltidy to match the author as close as I can. I try to encourage others to do the same.
- User23 4y ago
  > Perl is notorious for being "write only". > As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects. Perl gets quite unfairly picked on here, to the point where it's basically a meme. It's not like, just to pick a somewhat popular language, Ruby doesn't provide plenty of ways to write completely unreadable code that can only be understand by running it through irb, if even then. I agree that there is plenty of bad Perl code out there, but there's plenty of bad code in any language that achieves general popularity for a time. Disciplined use can produce perfectly clear and readable code and the module system is perfectly adequate for separation of concerns. The language does give you an absurd amount of rope to hang yourself with though. If I were managing a large Perl project today I'd have an extremely restrictive style guide and would enforce as much of it as possible via pre-commit hooks. > I feel qualified to say such things as I've worked on a billion-line perl codebase before. For a language that permits such densely expressive code, that's appalling. I'm so sorry.
- singhrac 4y ago
  I’ve worked on a Perl codebase written by a good programmer and had the pleasure of starting the port over to Python. This was surprisingly doable? Marshaling/unmarshaling Perl objects into Python ones isn’t difficult these days, and you can run Perl code via FFI so the transition can be piecemeal. I have no opinions on Perl as a language (some constructs / patterns felt a bit hard to think about, but I’m far from an expert), but ultimately it’s a high level language and has been left behind tooling wise to another high level language, so it’s time to move. For us, one motivator was that having a large legacy Perl codebase (even one running well for years) hurt recruiting.
mschuster91 4y ago
There once was a time when the only common things you could expect to be present on a Linux system were the good old `sh` (not `bash`) and a more or less old version of `perl`. The commands supported by `sh` are... let's keep it at "fossilized from somewhere in the 80s", and so the only alternative was perl which has a ... history of being not exactly user-friendly to code for.
- marcus0x62 4y ago
  Eh? Bash predates Linux by a couple of years. I don’t remember any early Linux system — my frame of reference begins in 1994 — without bash as the default shell.
  - edgyquant 4y ago
    Linux was built out initially with a hard coded call to bash
  - mschuster91 4y ago
    The common Debian expectation to this day is to keep acting like you only had POSIX shell features aka /bin/sh [1]. You may use /bin/bash if you like though. [1] https://www.debian.org/doc/debian-policy/ch-files.html#s-scripts https://www.debian.org/doc/debian-policy/ch-files.html#s-scr...
    - marcus0x62 4y ago
      That may be their expectation stylistically, but the first Debian release shipped[1] with bash as the default shell. I’m not aware of them ever having shipped the original Bourne shell. Your claim — that I was responding to - was that on early Linux systems you might only find the Bourne shell but not bash. That simply was not the case. 1 - http://archive.debian.org/debian-archive/debian/dists/buzz/main/source/base/ http://archive.debian.org/debian-archive/debian/dists/buzz/m...
- edgyquant 4y ago
  This is wrong, initially Linux was quite literally a bash kernel
werdnapk 4y ago
Perls big moto of TMTOWTDI always bugged me and I thought it was more of a negative than a plus which led to it being known for write-only code.
- chc 4y ago
  Rust is not so different from Perl in this regard — there are many ways to do practically everything. Do you want an argument that implements a trait? Cool, just use a generic with a trait bound (either specified as `<T: Trait>` or `<T> where T: Trait`). Or type the argument as `impl Trait`. Or take a `Box<dyn Trait>`.
  - a1369209993 4y ago
    I'm not particularly fluent in Rust, but at least several of those express meaningful differences in what you're doing, not just how. Eg are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return.
    - tialaramex 4y ago
      Whilst there are differences, that's not one of them. What decides whether the caller still has something is whether you passed it by reference. fn eat(food: Edible) just takes an actual Edible. Afterwards the food is gone, perhaps this function stashed it somewhere, or gave it away, but you don't have it any more† so maybe it was Dropped (destroyed) fn sniff(food: &Edible) -> Smell this time our function only wants an immutable reference to the Edible. The food isn't changed in any way by this predicate, it's still yours, and now you also know how it Smells. fn lick(food: &mut Edible) -> Review but this function modifies the Edible via the exclusive reference. You still have the food, and now you've got a Review, but the food may be changed, perhaps irreversibly by being licked. † If Edible is Copy then Rust will just copy it, so the caller still has it, types which are Copy are typically small, and they can't implement Drop, so if they were destroyed nothing happens anyway. An integer is Copy, a String isn't Copy, and neither is a File, or a network Socket, or whatever. You can make your own types Copy, if you want, and if they qualify.

Perl is notorious for being "write only". As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects. I feel qualified to say such things as I've worked on a billion-line perl codebase before.

bogeholm 4y ago
_one billion lines of Perl_? Wow
- School-Cotton 4y ago
  I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java. (I wouldn't be surprised if they still had sizable amounts of Perl in dark corners).
  - nkozyra 4y ago
    There's a spirograph guy in the corner, the only one left that knows perl, lurking out and trying to entice people with its merits. Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff. To be fair if I walked away from Rust for a year I'd probably be similarly lost.
    - dhosek 4y ago
      I still will reach for Perl for the occasional quick one-of text-processing application, but I do spend a lot of time in perldoc when I do.
  - Cthulhu_ 4y ago
    I can imagine corporate Java codebases can end up in the billion LOC as well. I mean it MIGHT be easier to read, or easier to find developers for... I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.
    - gautamdivgi 4y ago
      Ha ha no. Sorry to disappoint :) Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it. This isn’t an indictment of Java. Just resume driven design.
      - rhacker 4y ago
        That's why I left Java 5 years (after like a 12 year career in it) ago and plan on never getting another Java job. It's just making classes have "some" kind of use no matter what the task is, there's no coding to solve problems, it's coding to make structure.
        gautamdivgi 4y ago
        To be fair, I’ve seen this in c++ as well. Building an entire structure of classes like “java” and then using “design patterns” on those abstractions. All to implement a simple 7 step socket communication protocol. It was a “wtf is going on here moment”?
        rhacker 4y ago
        I was also part of it. I did my own share of - well if we design it this way then we can have a second "type" that does X with the same interface. And it just keeps on iterating like that. It's still a useful pattern, but often at least in my own case, overused for really trivial stuff. Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.
  - VyseofArcadia 4y ago
    With Java? I usually think of Perl as a glue language, like bash scripting. Java would not be my choice to glue components together.
    - dhosek 4y ago
      Nah, Perl can be a perfectly fine applications language. Some things get kind of ugly with it (object-orientation is notoriously hacky and there are two different approaches to classes that take inverse (literally) approaches to how to represent the objects in terms of Perl’s scalars, arrays and maps. It does suffer a bit from being an early mover so there are questionable choices like the fact that library code is traditionally installed system-wide so good luck if application A needs library v3 an application B needs v2 and v2 and v3 have some subtle incompatibility, but Perl is no less capable than Python and arguably more capable than PHP, both of which have plenty of applications written in them.
    - School-Cotton 4y ago
      Perl was the primary application-layer language at Amazon. It was used for most things that didn't need to be in a low-level language for performance or other reasons (for those, C++ was used instead).
  - thesuperbigfrog 4y ago
    >> I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java. The Amazon retail website (amazon.com and related versions for various countries) used the Perl Mason templating system (https://masonbook.houseabsolute.com/ https://masonbook.houseabsolute.com/) to allow various teams to build web site components in a performant and secure way. It worked quite well since it ran quickly and isolated components so that only one small change could be made without breaking other components.
- twic 4y ago
  Could have been worse. Could all have been on one line.
hardware2win 4y ago
Bilion lines? What, how? Thats bigger than windows linux llvm chromium and 5 other compilers combined according to google
- dijit 4y ago
  Commentary on that was made at the time. Linux is a pretty small codebase compared to most proprietary codebases in large companies to be fair though.
  - angrygoat 4y ago
    Yeah, this – it's easy to forget that infrastructure code (Linux, libc, openssl, ...) really is the tip of the iceberg. Industrial codebases are often at least an order of magnitude bigger; really, that shouldn't surprise us: there are so many problems to be solved, it should be unsurprising that the specific outweighs the general.
belter 4y ago
Shudder in horror.... "Booking.com uses the Perl programming language heavily across its entire technical infrastructure." - https://medium.com/booking-com-development/a-faster-perl-runtime-in-tiny-steps-97a1191d75e5 https://medium.com/booking-com-development/a-faster-perl-run...
- klabb3 4y ago
  Dad, let's go home. Please.
LinuxBender 4y ago
I've often found I could work around the "write only" mantra using perltidy. I pass other peoples code to perltidy with the flags that match my style, make changes, then pass it back through perltidy to match the author as close as I can. I try to encourage others to do the same.
User23 4y ago
> Perl is notorious for being "write only". > As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects. Perl gets quite unfairly picked on here, to the point where it's basically a meme. It's not like, just to pick a somewhat popular language, Ruby doesn't provide plenty of ways to write completely unreadable code that can only be understand by running it through irb, if even then. I agree that there is plenty of bad Perl code out there, but there's plenty of bad code in any language that achieves general popularity for a time. Disciplined use can produce perfectly clear and readable code and the module system is perfectly adequate for separation of concerns. The language does give you an absurd amount of rope to hang yourself with though. If I were managing a large Perl project today I'd have an extremely restrictive style guide and would enforce as much of it as possible via pre-commit hooks. > I feel qualified to say such things as I've worked on a billion-line perl codebase before. For a language that permits such densely expressive code, that's appalling. I'm so sorry.
singhrac 4y ago
I’ve worked on a Perl codebase written by a good programmer and had the pleasure of starting the port over to Python. This was surprisingly doable? Marshaling/unmarshaling Perl objects into Python ones isn’t difficult these days, and you can run Perl code via FFI so the transition can be piecemeal. I have no opinions on Perl as a language (some constructs / patterns felt a bit hard to think about, but I’m far from an expert), but ultimately it’s a high level language and has been left behind tooling wise to another high level language, so it’s time to move. For us, one motivator was that having a large legacy Perl codebase (even one running well for years) hurt recruiting.

mschuster91 4y ago

There once was a time when the only common things you could expect to be present on a Linux system were the good old `sh` (not `bash`) and a more or less old version of `perl`. The commands supported by `sh` are... let's keep it at "fossilized from somewhere in the 80s", and so the only alternative was perl which has a ... history of being not exactly user-friendly to code for.

marcus0x62 4y ago
Eh? Bash predates Linux by a couple of years. I don’t remember any early Linux system — my frame of reference begins in 1994 — without bash as the default shell.
- edgyquant 4y ago
  Linux was built out initially with a hard coded call to bash
- mschuster91 4y ago
  The common Debian expectation to this day is to keep acting like you only had POSIX shell features aka /bin/sh [1]. You may use /bin/bash if you like though. [1] https://www.debian.org/doc/debian-policy/ch-files.html#s-scripts https://www.debian.org/doc/debian-policy/ch-files.html#s-scr...
  - marcus0x62 4y ago
    That may be their expectation stylistically, but the first Debian release shipped[1] with bash as the default shell. I’m not aware of them ever having shipped the original Bourne shell. Your claim — that I was responding to - was that on early Linux systems you might only find the Bourne shell but not bash. That simply was not the case. 1 - http://archive.debian.org/debian-archive/debian/dists/buzz/main/source/base/ http://archive.debian.org/debian-archive/debian/dists/buzz/m...
edgyquant 4y ago
This is wrong, initially Linux was quite literally a bash kernel

werdnapk 4y ago

Perls big moto of TMTOWTDI always bugged me and I thought it was more of a negative than a plus which led to it being known for write-only code.

chc 4y ago
Rust is not so different from Perl in this regard — there are many ways to do practically everything. Do you want an argument that implements a trait? Cool, just use a generic with a trait bound (either specified as `<T: Trait>` or `<T> where T: Trait`). Or type the argument as `impl Trait`. Or take a `Box<dyn Trait>`.
- a1369209993 4y ago
  I'm not particularly fluent in Rust, but at least several of those express meaningful differences in what you're doing, not just how. Eg are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return.
  - tialaramex 4y ago
    Whilst there are differences, that's not one of them. What decides whether the caller still has something is whether you passed it by reference. fn eat(food: Edible) just takes an actual Edible. Afterwards the food is gone, perhaps this function stashed it somewhere, or gave it away, but you don't have it any more† so maybe it was Dropped (destroyed) fn sniff(food: &Edible) -> Smell this time our function only wants an immutable reference to the Edible. The food isn't changed in any way by this predicate, it's still yours, and now you also know how it Smells. fn lick(food: &mut Edible) -> Review but this function modifies the Edible via the exclusive reference. You still have the food, and now you've got a Review, but the food may be changed, perhaps irreversibly by being licked. † If Edible is Copy then Rust will just copy it, so the caller still has it, types which are Copy are typically small, and they can't implement Drop, so if they were destroyed nothing happens anyway. An integer is Copy, a String isn't Copy, and neither is a File, or a network Socket, or whatever. You can make your own types Copy, if you want, and if they qualify.