3 ms·

tbh, I'm still sad that Python won against Perl during the heyday. Perl was and is still a fun language.

jamal-kumar 5y ago
Perl is cool but it's got a hell of a lot of cryptic operators for its syntax. They make sense after you learn them but for beginners it's clear why python gets picked up way easier. They're not having to think in symbols and stuff, it just looks more like a list of instructions rather than a mess of dollar signs and 'my' (my what? just not retrospectively intuitive...) That said I like perl (And lately, awk/sed) a lot more for things that python is just SLOW at. Plus for systems-level scripts, considering that most linux/BSD installs you encounter on anything at all will have perl installed, let's say you encounter a router or something like that you need to work on somehow internally -- Do you even have room for another interpreter on there? Better be at least initiated in using perl if you want to hack on that. I've also recently found it really useful for rescuing an ancient database file format from the 1980s which was super handy considering other tools choked on it.
- ChrisMarshallNY 5y ago
  > Plus for systems-level scripts I still tend to use it for that.
  - jamal-kumar 5y ago
    Conversely, there's also so many things you can do in a perl (or awk/sed if performance or avoiding malloc by streaming data is necessary) oneliner in a shell script if you know some cool tricks. It's crazy how many resources are thrown into stuff like hadoop (literal ironic elephant logo) clusters to process CSV when dinky tools older than I am can zip through that data 1000x faster just by keeping it in the processor cache on my laptop https://learnbyexample.github.io/learn_perl_oneliners/cover.html https://learnbyexample.github.io/learn_perl_oneliners/cover....
- qalmakka 5y ago
  Perl might be weird, but it's logic and it makes sense. References are not automagical, but explicit, so you don't get an inconsistent function calling model. If you call a sub like `something(%h)`, it will get a copy of the hash. If you use `something(\%h)` the sub will receive a reference to access the hash instead. This is way better than Python or Java where everything is "pass-by-reference" until it isn't, and the fact a function won't modify the arguments you passed to it is basically a gentleman's agreement. Perl is complex, but it is also rewarding when you use it for those tasks it's good at (like gluing code together and text processing).
  - datameta 5y ago
    Ive only used Perl for one story at work but I don't fully grok yet why we $ a @ or a % Getting a hash passed by ref to a sub was a true syntactic challenge that I haven't experienced in a different language. Have to say though, using regex in Perl is chef's kiss
    - qalmakka 5y ago
      Because an array is a list of scalar, and an hash a map of scalars. If you want to access a scalar inside the list, you write $a[1], which means "the scalar at the first position of list @a". If it was @a[1] it would have been inconsistent, because then a @ expression would have returned a scalar and not a list.
qalmakka 5y ago
In my heart, Perl has won a long time ago. Python is nice and all, but it's too much of a jack of all trades language, that doesn't neither suck nor shine at anything. Also, the fact you can write a Perl script, run it everywhere and just not concern yourself with versioning and stuff is beautiful. If one of my .sh script gets over 40 lines, it becomes a .pl file, that's the rule.
- alfiedotwtf 5y ago
  Yeah, same. I start off as a shell, but if it starts to get beyond simple text manipulation of variable, I switch it up.
lenkite 5y ago
If Perl had offered proper OO without all that convoluted bless stuff, offered proper linting, good data-science libs like pandas, easy concurrency, ergonomical web-frameworks to beat PHP and did not get lost in the "everything will be solved by Perl 6" argument, it could have ruled as the Camel of the Web. Sadly it was not to be.
- kbenson 5y ago
  > proper OO without all that convoluted bless stuff Moose[1], and more lightweight versions in Mouse[2] and Moo[3], have been around for ages by this point, almost 15 years in some cases. Unfortunately it was never made core (but something like them is supposed to be core in Perl 7), so it was always one of the "best practices" things that you had to be in contact with other people about Perl to know or read some Perl community stuff for, as it wasn't in the official docs. > good data-science libs like pandas To my knowledge Perl with PDL[4] was the go-to solution for bioinformatics people for a long time. I never did anything with it or Python's Pandas though, so I don't know how they compare (or more importantly, how they compared back when people actually used Perl for this stuff much). > easy concurrency While somewhat wonky, Perl's concurrency has been around in forms for a long time (the Coro[5] library was first released in 2001), if a bit harder to use until recently when like every other language the async/await stuff took over. The parallelism story has always been pretty good, even if also slightly weird (the ithreads system used forks on Unix to emulate threads, but essentially it's an abstraction you can mostly ignore). Notably, the fact you actually had a threading system[6] with locks and semaphores that worked put it above Python and Ruby in that category. > ergonomical web-frameworks to beat PHP This took longer, but Mojolicious[7] seems to fit this category well, easily being used as simple as something like Sinatra to stuff close to Rails (IMO, and without ActiveRecord). That's not to say Perl is perfect and should have always won out, just that I think the problems Perl experienced (and still experiences, and which recently "Perl 7" is trying to address) are more along the lines of the trade off that was made with regard to backwards compatibility and legacy support, and the effect that had long term on the community. Perl's absolute adherence to backwards compatibility to the point that 20 year old scripts often run without issue on the latest release of the interpreter was always a boon to those that wanted stability and support. It's still used in some places (for example, where I work) as the primary scripting language for server based utilities that are expected to run in a Unix environment. The problem is that this is a trade-off that hurts more for new users and new technologies as time advances. It's great that our (literally) 20 year old scripts to clean up and do server management still function, but it's not as great that ergonomically Perl requirement to opt-in to many new features (so they don't cause old code with conflicting sub names to fail, as an example) means that there's been an ever increasing list of things you must enable in new Perl lest you deal with annoying old behavior makes it's use for new projects annoying at best. Having a good object system is only the first step, and you're right to call it out because as it was never moved to core, it never got as much use as it could have. > Sadly it was not to be. It is sad, because it's a nice language and I love using it most of the time, but I also feel like it wasted well over a decade of what should have been major advances because it was deemed less important than backwards compat and everybody just said "well there's a module for it, that's good enough" when it definitely wasn't sufficient. For chrissakes, Perl only got the most simplistic form of function signatures relatively recently, and what we got is far inferior to what was available and I used as a module a decade ago[8]. Perl's problems were always much deeper than not having some solution or equivalent to some nice tool or way of doing things in other languages. Those came, usually fairly quickly, it was all the other stuff that shed the users to the point that now it's hard to know if there's enough left to drive the change that's needed to keep it alive (in the sense that it's not just in bug maintenance mode). Sorry for the rant. Obviously I'm sad about the current state of things... I've even mostly decided that I might as well do new projects in other languages, but it makes me sad that it feels like I'm doing so not because they're mostly superior at a level that's hard to compete with but because the Perl community (and this includes myself) couldn't get their shit together long enough to steal the good bits in a way that actually mattered to people looking to try a new language. 1: https://en.wikipedia.org/wiki/Moose_(Perl)#Examples https://en.wikipedia.org/wiki/Moose_(Perl)#Examples 2: https://metacpan.org/pod/Mouse#SYNOPSIS https://metacpan.org/pod/Mouse#SYNOPSIS 3: https://metacpan.org/pod/Moo#SYNOPSIS https://metacpan.org/pod/Moo#SYNOPSIS 4: http://pdl.perl.org/ http://pdl.perl.org/ 5: https://metacpan.org/pod/Coro#SYNOPSIS https://metacpan.org/pod/Coro#SYNOPSIS 6: https://metacpan.org/pod/threads::shared https://metacpan.org/pod/threads::shared 7: https://mojolicious.org/ https://mojolicious.org/ 8: Function::Parameters, as in the bottom of this comment https://news.ycombinator.com/item?id=11633961 https://news.ycombinator.com/item?id=11633961, as the CPAN page does a crap job of showing it with types which is my favorite part.

Perl is cool but it's got a hell of a lot of cryptic operators for its syntax. They make sense after you learn them but for beginners it's clear why python gets picked up way easier. They're not having to think in symbols and stuff, it just looks more like a list of instructions rather than a mess of dollar signs and 'my' (my what? just not retrospectively intuitive...) That said I like perl (And lately, awk/sed) a lot more for things that python is just SLOW at. Plus for systems-level scripts, considering that most linux/BSD installs you encounter on anything at all will have perl installed, let's say you encounter a router or something like that you need to work on somehow internally -- Do you even have room for another interpreter on there? Better be at least initiated in using perl if you want to hack on that. I've also recently found it really useful for rescuing an ancient database file format from the 1980s which was super handy considering other tools choked on it.

ChrisMarshallNY 5y ago
> Plus for systems-level scripts I still tend to use it for that.
- jamal-kumar 5y ago
  Conversely, there's also so many things you can do in a perl (or awk/sed if performance or avoiding malloc by streaming data is necessary) oneliner in a shell script if you know some cool tricks. It's crazy how many resources are thrown into stuff like hadoop (literal ironic elephant logo) clusters to process CSV when dinky tools older than I am can zip through that data 1000x faster just by keeping it in the processor cache on my laptop https://learnbyexample.github.io/learn_perl_oneliners/cover.html https://learnbyexample.github.io/learn_perl_oneliners/cover....
qalmakka 5y ago
Perl might be weird, but it's logic and it makes sense. References are not automagical, but explicit, so you don't get an inconsistent function calling model. If you call a sub like `something(%h)`, it will get a copy of the hash. If you use `something(\%h)` the sub will receive a reference to access the hash instead. This is way better than Python or Java where everything is "pass-by-reference" until it isn't, and the fact a function won't modify the arguments you passed to it is basically a gentleman's agreement. Perl is complex, but it is also rewarding when you use it for those tasks it's good at (like gluing code together and text processing).
- datameta 5y ago
  Ive only used Perl for one story at work but I don't fully grok yet why we $ a @ or a % Getting a hash passed by ref to a sub was a true syntactic challenge that I haven't experienced in a different language. Have to say though, using regex in Perl is chef's kiss
  - qalmakka 5y ago
    Because an array is a list of scalar, and an hash a map of scalars. If you want to access a scalar inside the list, you write $a[1], which means "the scalar at the first position of list @a". If it was @a[1] it would have been inconsistent, because then a @ expression would have returned a scalar and not a list.

qalmakka 5y ago

In my heart, Perl has won a long time ago. Python is nice and all, but it's too much of a jack of all trades language, that doesn't neither suck nor shine at anything. Also, the fact you can write a Perl script, run it everywhere and just not concern yourself with versioning and stuff is beautiful. If one of my .sh script gets over 40 lines, it becomes a .pl file, that's the rule.

alfiedotwtf 5y ago
Yeah, same. I start off as a shell, but if it starts to get beyond simple text manipulation of variable, I switch it up.

lenkite 5y ago

If Perl had offered proper OO without all that convoluted bless stuff, offered proper linting, good data-science libs like pandas, easy concurrency, ergonomical web-frameworks to beat PHP and did not get lost in the "everything will be solved by Perl 6" argument, it could have ruled as the Camel of the Web. Sadly it was not to be.

kbenson 5y ago
> proper OO without all that convoluted bless stuff Moose[1], and more lightweight versions in Mouse[2] and Moo[3], have been around for ages by this point, almost 15 years in some cases. Unfortunately it was never made core (but something like them is supposed to be core in Perl 7), so it was always one of the "best practices" things that you had to be in contact with other people about Perl to know or read some Perl community stuff for, as it wasn't in the official docs. > good data-science libs like pandas To my knowledge Perl with PDL[4] was the go-to solution for bioinformatics people for a long time. I never did anything with it or Python's Pandas though, so I don't know how they compare (or more importantly, how they compared back when people actually used Perl for this stuff much). > easy concurrency While somewhat wonky, Perl's concurrency has been around in forms for a long time (the Coro[5] library was first released in 2001), if a bit harder to use until recently when like every other language the async/await stuff took over. The parallelism story has always been pretty good, even if also slightly weird (the ithreads system used forks on Unix to emulate threads, but essentially it's an abstraction you can mostly ignore). Notably, the fact you actually had a threading system[6] with locks and semaphores that worked put it above Python and Ruby in that category. > ergonomical web-frameworks to beat PHP This took longer, but Mojolicious[7] seems to fit this category well, easily being used as simple as something like Sinatra to stuff close to Rails (IMO, and without ActiveRecord). That's not to say Perl is perfect and should have always won out, just that I think the problems Perl experienced (and still experiences, and which recently "Perl 7" is trying to address) are more along the lines of the trade off that was made with regard to backwards compatibility and legacy support, and the effect that had long term on the community. Perl's absolute adherence to backwards compatibility to the point that 20 year old scripts often run without issue on the latest release of the interpreter was always a boon to those that wanted stability and support. It's still used in some places (for example, where I work) as the primary scripting language for server based utilities that are expected to run in a Unix environment. The problem is that this is a trade-off that hurts more for new users and new technologies as time advances. It's great that our (literally) 20 year old scripts to clean up and do server management still function, but it's not as great that ergonomically Perl requirement to opt-in to many new features (so they don't cause old code with conflicting sub names to fail, as an example) means that there's been an ever increasing list of things you must enable in new Perl lest you deal with annoying old behavior makes it's use for new projects annoying at best. Having a good object system is only the first step, and you're right to call it out because as it was never moved to core, it never got as much use as it could have. > Sadly it was not to be. It is sad, because it's a nice language and I love using it most of the time, but I also feel like it wasted well over a decade of what should have been major advances because it was deemed less important than backwards compat and everybody just said "well there's a module for it, that's good enough" when it definitely wasn't sufficient. For chrissakes, Perl only got the most simplistic form of function signatures relatively recently, and what we got is far inferior to what was available and I used as a module a decade ago[8]. Perl's problems were always much deeper than not having some solution or equivalent to some nice tool or way of doing things in other languages. Those came, usually fairly quickly, it was all the other stuff that shed the users to the point that now it's hard to know if there's enough left to drive the change that's needed to keep it alive (in the sense that it's not just in bug maintenance mode). Sorry for the rant. Obviously I'm sad about the current state of things... I've even mostly decided that I might as well do new projects in other languages, but it makes me sad that it feels like I'm doing so not because they're mostly superior at a level that's hard to compete with but because the Perl community (and this includes myself) couldn't get their shit together long enough to steal the good bits in a way that actually mattered to people looking to try a new language. 1: https://en.wikipedia.org/wiki/Moose_(Perl)#Examples https://en.wikipedia.org/wiki/Moose_(Perl)#Examples 2: https://metacpan.org/pod/Mouse#SYNOPSIS https://metacpan.org/pod/Mouse#SYNOPSIS 3: https://metacpan.org/pod/Moo#SYNOPSIS https://metacpan.org/pod/Moo#SYNOPSIS 4: http://pdl.perl.org/ http://pdl.perl.org/ 5: https://metacpan.org/pod/Coro#SYNOPSIS https://metacpan.org/pod/Coro#SYNOPSIS 6: https://metacpan.org/pod/threads::shared https://metacpan.org/pod/threads::shared 7: https://mojolicious.org/ https://mojolicious.org/ 8: Function::Parameters, as in the bottom of this comment https://news.ycombinator.com/item?id=11633961 https://news.ycombinator.com/item?id=11633961, as the CPAN page does a crap job of showing it with types which is my favorite part.