10 ms·

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to an

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.

earthboundkid 6y ago
Perl definitely has a lot of non-patterned arcana. For instance, $| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0. In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
- rlpb 6y ago
  I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.
  - ljm 6y ago
    `use English;` as a directive feels like the programming equivalent of someone on TV saying "ye ye ye can you say that in English!?" Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
  - jschwartzi 6y ago
    The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.
    - gbacon 6y ago
      What do you mean the documentation doesn’t cover them? https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES
- mfontani 6y ago
  One can also: use IO::Handle; STDOUT->autoflush(1); STDERR->autoflush(1);
  - justinator 6y ago
    TMTOWTDI!
    - laumars 6y ago
      TIMTOWTDIBSCINABTE (for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
    - daotoad 6y ago
      TIMTOWTDIBSCINABTE (pronounced "tim toady bicarbonate"). "There’s more than one way to do it, but sometimes consistency is not a bad thing either."
- joosters 6y ago
  Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.
  - DonHopkins 6y ago
    That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code. If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool. Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn. If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
    - joosters 6y ago
      Because perl improved over time, but they didn't want to break people's existing code needlessly. No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.
      - DonHopkins 6y ago
        The concept of giving functions names spelled out with letters that form words that describe their meaning was invented a long time before Perl figured out that doing that was better than overloading a limited set of ASCII punctuation with random abstract unrelated concepts.
        6y ago
- wbl 6y ago
  $| is related to pipes. Much of the sigils are like this.
  - proverbialbunny 6y ago
    It suddenly makes sense and isn't so bad. The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
    - cutler 6y ago
      In Perl `$` is strictly a scalar variable though this can be a reference to an array, hash or object as they are stored as references. Not to be confused with `$` in PHP which simply denotes a variable of any kind. In Bash `$` denotes the value of a variable.
peterwwillis 6y ago
> You learn perl, and you've learned nothing but Larry Wall. Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose. Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
- marksomnian 6y ago
  JavaScript probably can, or at least mostly. That's where a lot of its problems come from, historical baggage.
  - btilly 6y ago
    JavaScript didn't exist 25 years ago. (The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
- BruceEel 6y ago
  Not a Microsoft fan, but simple C / Windows API code from 25 years ago would likely compile and run on Windows 10 unchanged. My limited experience with Swift suggests that even 25 hours ago could be a tall order...
  - anthk 6y ago
    Eh, simple C code with X11/Motif will compile fine under Unix too.
  - kazinator 6y ago
    Moreover, a Windows .exe compiled 25 years ago will also likely just run.
    - jcranmer 6y ago
SuspiciousSwan 6y ago
I think you should revisit perl. My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages. I think it was my coworker who told me to read https://hop.perl.plover.com/ https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other. Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse. It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that. Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages. I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
- alexchantavy 6y ago
  Do you have a good link to learn about grammars in perl?
  - lizmat 6y ago
    Perl does not have grammars (at least, not built-in). Raku (formerly known as Perl 6) does: https://docs.raku.org/language/grammar_tutorial https://docs.raku.org/language/grammar_tutorial
staycoolboy 6y ago
Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.
- freedomben 6y ago
  Awk and Ruby aren't on your list, any experience with those that you could compare/contrast with Perl?
  - staycoolboy 6y ago
    Awk is very similar in syntax, but doesn't provide the sophistication of match vs subst, and doesn't support suffix modifiers. I only used Ruby briefly over 20 years ago so I can't comment.
- aduitsis 6y ago
  Favorite syntactic sugar feature: the /x modifier which makes the regex ignore spaces and comments, meaning you can break your regex into multiple lines and comment them.
  - staycoolboy 6y ago
    Have you ever read O'Reilly's "Mastering Regular Expressions" by Friedl? He does a deep dive into the weird guts of regex modifiers. I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
    - cutler 6y ago
      Friedl's masterpiece was my introduction to server-side programming in 2000. I'd been doing front-end for a few years with Dreamweaver and I was looking-up it's find & replace features in "Dreamweaver Bible 8" where regexes were mentioned as the ultimate weapon. "Mastering Regular Expressions" was referenced in a footnote and fortunately my local library had a copy. My mind was blown. Regex symbols were just so powerful and the examples were mainly written in Perl which added even more power to them. The book was part of O'Reilly's Perl bookshelf so in addition to Friedl's book I bought the other Perl classics - "Programming Perl", "Perl Cookbook", "Mastering Algorithms with Perl" and "Learning Perl". With CPAN downloaded to my local disk I felt like a hitch-hiker setting out on a journey around the world needing nothing more than Perl in my backpack. Those were the days. Now I have to download 200Mb of node_modules before I can get started.
notyourday 6y ago
> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
- btilly 6y ago
  I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks. The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines: my $bar = foo(); my ($baz) = foo(); I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.
  - lizmat 6y ago
    This is why Raku doesn't have contexts in that sense. All a subroutine or method can ever return, is a single object. Such an object can be a List or an Array, but it is still a single value.
  - notyourday 6y ago
    Return a reference to a hash. You are done.
  - kbenson 6y ago
    Whether context is good or bad, a success or a mistake, there's no denying it is either one of the most or the most important idea in Perl. That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing. That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
7thaccount 6y ago
The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.
- notyourday 6y ago
  I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.
  - singingfish 6y ago
    Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny
- lizmat 6y ago
  At least one of the inspirations of Moose, was the object system of Perl 6 at the time (now Raku https://raku.org https://raku.org using the #rakulang tag on social media). To create a Point class that has an x and a y attribute, you'd write: class Point { has $.x; has $.y; } Object instantiation is then done with: Point.new(x => 42, y => 666);
  - 7thaccount 6y ago
    Forgot about the inspiration from P6 (Raku). Thanks for mentioning Liz!
rcthompson 6y ago
On the subject of transferrable knowledge, Perl was the first language I learned, and I was always a little bit confused about why every language I learned since then didn't have pronouns, until finally magrittr came along in R and made perfect sense to me, since "." in magrittr/dplyr feels a lot like "$_" (or "@_") in Perl.
singingfish 6y ago
Perl’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo
deckard1 6y ago
> Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used. Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
- worik 6y ago
  OOP will rot your teeth.
sateesh 6y ago
I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code. True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.

earthboundkid 6y ago

Perl definitely has a lot of non-patterned arcana. For instance, $| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0. In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.

rlpb 6y ago
I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.
- ljm 6y ago
  `use English;` as a directive feels like the programming equivalent of someone on TV saying "ye ye ye can you say that in English!?" Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
- jschwartzi 6y ago
  The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.
  - gbacon 6y ago
    What do you mean the documentation doesn’t cover them? https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES https://perldoc.perl.org/perlvar.html#SPECIAL-VARIABLES
mfontani 6y ago
One can also: use IO::Handle; STDOUT->autoflush(1); STDERR->autoflush(1);
- justinator 6y ago
  TMTOWTDI!
  - laumars 6y ago
    TIMTOWTDIBSCINABTE (for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
  - daotoad 6y ago
    TIMTOWTDIBSCINABTE (pronounced "tim toady bicarbonate"). "There’s more than one way to do it, but sometimes consistency is not a bad thing either."
joosters 6y ago
Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.
- DonHopkins 6y ago
  That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code. If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool. Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn. If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
  - joosters 6y ago
    Because perl improved over time, but they didn't want to break people's existing code needlessly. No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.
    - DonHopkins 6y ago
      The concept of giving functions names spelled out with letters that form words that describe their meaning was invented a long time before Perl figured out that doing that was better than overloading a limited set of ASCII punctuation with random abstract unrelated concepts.
      - 6y ago
wbl 6y ago
$| is related to pipes. Much of the sigils are like this.
- proverbialbunny 6y ago
  It suddenly makes sense and isn't so bad. The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
  - cutler 6y ago
    In Perl `$` is strictly a scalar variable though this can be a reference to an array, hash or object as they are stored as references. Not to be confused with `$` in PHP which simply denotes a variable of any kind. In Bash `$` denotes the value of a variable.

peterwwillis 6y ago

> You learn perl, and you've learned nothing but Larry Wall. Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose. Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)

marksomnian 6y ago
JavaScript probably can, or at least mostly. That's where a lot of its problems come from, historical baggage.
- btilly 6y ago
  JavaScript didn't exist 25 years ago. (The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
BruceEel 6y ago
Not a Microsoft fan, but simple C / Windows API code from 25 years ago would likely compile and run on Windows 10 unchanged. My limited experience with Swift suggests that even 25 hours ago could be a tall order...
- anthk 6y ago
  Eh, simple C code with X11/Motif will compile fine under Unix too.
- kazinator 6y ago
  Moreover, a Windows .exe compiled 25 years ago will also likely just run.
  - jcranmer 6y ago

SuspiciousSwan 6y ago

I think you should revisit perl. My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages. I think it was my coworker who told me to read https://hop.perl.plover.com/ https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other. Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse. It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that. Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages. I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.

alexchantavy 6y ago
Do you have a good link to learn about grammars in perl?
- lizmat 6y ago
  Perl does not have grammars (at least, not built-in). Raku (formerly known as Perl 6) does: https://docs.raku.org/language/grammar_tutorial https://docs.raku.org/language/grammar_tutorial

staycoolboy 6y ago

Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.

freedomben 6y ago
Awk and Ruby aren't on your list, any experience with those that you could compare/contrast with Perl?
- staycoolboy 6y ago
  Awk is very similar in syntax, but doesn't provide the sophistication of match vs subst, and doesn't support suffix modifiers. I only used Ruby briefly over 20 years ago so I can't comment.
aduitsis 6y ago
Favorite syntactic sugar feature: the /x modifier which makes the regex ignore spaces and comments, meaning you can break your regex into multiple lines and comment them.
- staycoolboy 6y ago
  Have you ever read O'Reilly's "Mastering Regular Expressions" by Friedl? He does a deep dive into the weird guts of regex modifiers. I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
  - cutler 6y ago
    Friedl's masterpiece was my introduction to server-side programming in 2000. I'd been doing front-end for a few years with Dreamweaver and I was looking-up it's find & replace features in "Dreamweaver Bible 8" where regexes were mentioned as the ultimate weapon. "Mastering Regular Expressions" was referenced in a footnote and fortunately my local library had a copy. My mind was blown. Regex symbols were just so powerful and the examples were mainly written in Perl which added even more power to them. The book was part of O'Reilly's Perl bookshelf so in addition to Friedl's book I bought the other Perl classics - "Programming Perl", "Perl Cookbook", "Mastering Algorithms with Perl" and "Learning Perl". With CPAN downloaded to my local disk I felt like a hitch-hiker setting out on a journey around the world needing nothing more than Perl in my backpack. Those were the days. Now I have to download 200Mb of node_modules before I can get started.

notyourday 6y ago

> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.

btilly 6y ago
I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks. The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines: my $bar = foo(); my ($baz) = foo(); I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.
- lizmat 6y ago
  This is why Raku doesn't have contexts in that sense. All a subroutine or method can ever return, is a single object. Such an object can be a List or an Array, but it is still a single value.
- notyourday 6y ago
  Return a reference to a hash. You are done.
- kbenson 6y ago
  Whether context is good or bad, a success or a mistake, there's no denying it is either one of the most or the most important idea in Perl. That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing. That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).

7thaccount 6y ago

The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.

notyourday 6y ago
I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.
- singingfish 6y ago
  Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny
lizmat 6y ago
At least one of the inspirations of Moose, was the object system of Perl 6 at the time (now Raku https://raku.org https://raku.org using the #rakulang tag on social media). To create a Point class that has an x and a y attribute, you'd write: class Point { has $.x; has $.y; } Object instantiation is then done with: Point.new(x => 42, y => 666);
- 7thaccount 6y ago
  Forgot about the inspiration from P6 (Raku). Thanks for mentioning Liz!

rcthompson 6y ago

On the subject of transferrable knowledge, Perl was the first language I learned, and I was always a little bit confused about why every language I learned since then didn't have pronouns, until finally magrittr came along in R and made perfect sense to me, since "." in magrittr/dplyr feels a lot like "$_" (or "@_") in Perl.

singingfish 6y ago

Perl’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo

deckard1 6y ago

> Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used. Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.

worik 6y ago
OOP will rot your teeth.

sateesh 6y ago

I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code. True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.