4 ms·
> 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, al
by 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.
- alfiedotwtf 5y ago>> proper OO without all that convoluted bless stuff > >Moose[1], and more lightweight versions in Mouse[2] and Moo[3] I found all those frameworks, and hacking with inside-out objects to be too cumbersome and got in the way, so I just went back to blessed hashes. I liked to keep things simple. > easy concurrency I never got into Coro, but AnyEvent was wonderful to work with, and shaped my thinking in other languages... though you could get away with much more in Perl. > ergonomical web-frameworks to beat PHP I don't know how anything could be more ergonomic than Dancer (Perl's Sinatra equivalent). > but I also feel like it wasted well over a decade of what should have been major advances This, but thinking back at the time, I think what killed Perl was Google choosing Python. At the time, CPAN was the killer app and still had the lead vs all other higher-level languages. But then Google chose Perl instead of Python and as it was the hottest startup at the time where everyone wanted to work at, people started learning Python. Then the data scientists (except the geneticists) migrated over and NumPy, Pandas (and now TensorFlow) kept the momentum.
- kbenson 5y ago> I don't know how anything could be more ergonomic than Dancer (Perl's Sinatra equivalent). My understanding it that they're very equivalent in many respects, and popped up at about the same time. Often they're mentioned together as modern options, I didn't for brevity and I'm familiar with Mojo. I think Mojolivious tries to require only core modules with optional upgrade to non-core versions if supplied. Not sure how that compares with Dancer, been a long time since I looked at it. > I think what killed Perl was Google choosing Python. Possibly. I saw that as the natural extension of "python is the new teaching language" stuff that started happening in colleges at around the same time, and I think that had a lot to do with it as well. I'm the end it's all about users, and new users, as old users have a natural attrition through finding other things that interest them (whether a new language or non programming pursuits) or retirement or even death. Without new users eventually the community starves. And even if you get enough new users to replace the old ones, without enough new to keep a relevant position relative to all new users, the language will be relegated to a slow decay. That is, even if perl had enough new users to replace old ones, the total programmers grew manifold over the last decades, and without a slice of that pie you're stuck as a has-been language, and eventually people leave due to the natural pull of popular and vibrant language communities.