I haven't done anything with Perl since 4.036 in the late 90s, so I haven't kept up with all the Raku stuff. From that outsider perspective my first reaction to this was "how many languages are they going to turn Perl into?"
There's a perl 5.
There's no perl 6 because it's too much not like perl.
There's a perl 7 but it looks like it'll have two totally different syntaxes for stuff
And maybe there's a perl 8 but maybe with the same syntax as one of the flavors of 7?
I still see no compelling reason to get interested in perl. I have python for some stuff and go for some other stuff. What does perl do for me that these two can't?
Python and Go are pathologically bad at the things Perl does well.
I still use one-liners all the time, and when I need to implement a non-trivial, but small stream transformation, the resulting perl is << 1/10th the size of the unmaintainable python my coworkers would write.
Perl is so ubiquitous that makes awk and sed pretty redundant, if not outright worse. Perl regular expressions are so much better than whatever ugly mishmash sed uses that I haven't touched it in years.
I usually use perl with a combination of cut, grep and sort. If I had awk and sed in muscle memory, I’d definitely use them in some places where I use perl (awk and sed require fewer keystrokes for certain tasks).
I also like using perl for non-trivial stuff. For instance: parse a file, stick stuff in a hashtable or two, then iterate over the keys in sorted order, check a bunch of invariants, and then emit some other wonky format by chasing keys in the hashtables.
Some day, I hope to master the techniques in this book:
Perl is dead like COBOL, Visual Basic, and Pascal.
There was so much code written in Perl it will be a long time before it truly dies. It was the duct tape of the internet for almost a decade and it’s still probably the best way to efficiently manipulate text.
Not quite - that was his initial implementation which he described as "That’s not good at all, but I was trying to work within Perl’s limitations". The corinna syntax is
class Point {
field ( $x, $y ) :param = 0;
method clear () {
( $x, $y ) = ( 0, 0 );
}
}
class Point {
has $x = 0;
has $y = 0;
sub clear {
$x = $y = 0;
}
}
At least that's how I implemented it in the future perl, called cperl. Designed with perl6.
His perl cannot have array or hash fields, and his fields are still hash keys. Wtf
I'm always torn by these posts. I love perl's (well Moo's) class definitions - the simple, obvious way to make immutable objects combined with the `lazy` pattern fits really well with how I like to write code. But.
I have never quite got my head around the point of runtime constraints. If something passes bad data to a function, moo(se) throws an inscrutable error and I'm stuffed - there's no obvious way to recover, things just die. Static type checking tells you at compile time that you goofed, and then the system doesn't have to spend all that time checking every argument to every function every time it's called. PEP484, jsdoc + tsc & RBS show you can do this incrementally on existing code.
Huge amounts of existing perl code & libraries are not async-aware, so rewriting things to take into account concurrency is a huge undertaking. From Log4perl's global MDC through to pretty much every single file parser's blocking behaviour, there's so little code that can be reused from the perl5 oeuvre that I honestly think it's too late.
The fundamental issue here is that yes, all of these things could happen. We could assert that perl8 will be concurrent/async, have awesome runtime type checks etc etc. But why bother? Who is going to pay for it (aka spend time on it)?
The elephant in the room is that even if we did all this stuff - rewriting all the "core" libraries needed for a modern language to follow these awesome new paradigms (from json parsers, date libraries, web frameworks, database libraries - essentially, all of go's core libraries + a ton more), perl is still slow.
As hn discussed a few months ago, the author of mojolicious decided to try a JS version of mojolicious. His experience, like mine, was that even as a naive JS coder writing stupid schoolboy code, he saw a 5x+ speedup. Go is the same - a seasoned perl dev writing stupid, beginner go code results in >5x performance, and pretty much free concurrency.
It's almost embarrassing researching technologies these days. When was the last time you found something that provided perl support? We all know the hierarchy: Java, js, go, python, .net, rust. Then the next tiers: php, ruby, maybe scala, kotlin or swift. Maybe even the unexpected: dart, lua, OCaml. Perl? Maybe if someone on cpan wrote one. I honestly think the last first-party library I saw was mongodb, back around 2010 (the perl library is now officially EOL since 2018, obvs).
By all means write a new perl because you love it, but be honest with yourself in terms of what is achievable. No-one is going to spend the time/money/resource required to take the existing perl codebase and make it into a modern language that can compete with python, js, java, go or rust. And even then, what compelling/unique features can a "new" perl offer? Rust gained marketshare because it was safe with near-c performance. Go compiles & runs almost as fast as a dynamic language, compiles to a single binary, had an awesome core library, excellent performance and a compelling concurrency story. Nodejs had an critical mass of devs who already knew js from browsers, a bunch of highly-resourced companies competing to make it fast, and is getting better all the time (async/await, const/let etc etc).
I understand that people love languages, but sometimes we have to understand that perl is like Amiga (or blackberry, zune, or even scala (ooh, contentious)) - we can love a thing but understand that its time has been and gone. We can mourn what could have been, but there is no world in which Amiga will become a significant force again. Similarly, there is no world in which perl will gain significant marketshare again.
17 comments
[ 4.3 ms ] story [ 32.9 ms ] threadThere's a perl 5.
There's no perl 6 because it's too much not like perl.
There's a perl 7 but it looks like it'll have two totally different syntaxes for stuff
And maybe there's a perl 8 but maybe with the same syntax as one of the flavors of 7?
I still see no compelling reason to get interested in perl. I have python for some stuff and go for some other stuff. What does perl do for me that these two can't?
I still use one-liners all the time, and when I need to implement a non-trivial, but small stream transformation, the resulting perl is << 1/10th the size of the unmaintainable python my coworkers would write.
Though I understand what you are saying, I sometimes feel the same with combinations of awk, sed, and other utils.
Though I suspect perl could be more powerful for that kind of processing.
I also like using perl for non-trivial stuff. For instance: parse a file, stick stuff in a hashtable or two, then iterate over the keys in sorted order, check a bunch of invariants, and then emit some other wonky format by chasing keys in the hashtables.
Some day, I hope to master the techniques in this book:
https://en.wikipedia.org/wiki/The_AWK_Programming_Language
which includes an RDBMS and assembler + interpreter, and then culminates in a 4 page section that implements make.
At that point, I might be able to switch away from perl.
All that happened is Perl 6 became Raku because some people didn't want Perl changing that much.
So Perl will jump version 6 and naturally evolve into Perl 7 at some point.
There was so much code written in Perl it will be a long time before it truly dies. It was the duct tape of the internet for almost a decade and it’s still probably the best way to efficiently manipulate text.
Perl is dead, long live Perl.
If you want classes go use java or C#, the second and third most boring things in programming.
I have never quite got my head around the point of runtime constraints. If something passes bad data to a function, moo(se) throws an inscrutable error and I'm stuffed - there's no obvious way to recover, things just die. Static type checking tells you at compile time that you goofed, and then the system doesn't have to spend all that time checking every argument to every function every time it's called. PEP484, jsdoc + tsc & RBS show you can do this incrementally on existing code.
Huge amounts of existing perl code & libraries are not async-aware, so rewriting things to take into account concurrency is a huge undertaking. From Log4perl's global MDC through to pretty much every single file parser's blocking behaviour, there's so little code that can be reused from the perl5 oeuvre that I honestly think it's too late.
The fundamental issue here is that yes, all of these things could happen. We could assert that perl8 will be concurrent/async, have awesome runtime type checks etc etc. But why bother? Who is going to pay for it (aka spend time on it)?
The elephant in the room is that even if we did all this stuff - rewriting all the "core" libraries needed for a modern language to follow these awesome new paradigms (from json parsers, date libraries, web frameworks, database libraries - essentially, all of go's core libraries + a ton more), perl is still slow.
As hn discussed a few months ago, the author of mojolicious decided to try a JS version of mojolicious. His experience, like mine, was that even as a naive JS coder writing stupid schoolboy code, he saw a 5x+ speedup. Go is the same - a seasoned perl dev writing stupid, beginner go code results in >5x performance, and pretty much free concurrency.
It's almost embarrassing researching technologies these days. When was the last time you found something that provided perl support? We all know the hierarchy: Java, js, go, python, .net, rust. Then the next tiers: php, ruby, maybe scala, kotlin or swift. Maybe even the unexpected: dart, lua, OCaml. Perl? Maybe if someone on cpan wrote one. I honestly think the last first-party library I saw was mongodb, back around 2010 (the perl library is now officially EOL since 2018, obvs).
By all means write a new perl because you love it, but be honest with yourself in terms of what is achievable. No-one is going to spend the time/money/resource required to take the existing perl codebase and make it into a modern language that can compete with python, js, java, go or rust. And even then, what compelling/unique features can a "new" perl offer? Rust gained marketshare because it was safe with near-c performance. Go compiles & runs almost as fast as a dynamic language, compiles to a single binary, had an awesome core library, excellent performance and a compelling concurrency story. Nodejs had an critical mass of devs who already knew js from browsers, a bunch of highly-resourced companies competing to make it fast, and is getting better all the time (async/await, const/let etc etc).
I understand that people love languages, but sometimes we have to understand that perl is like Amiga (or blackberry, zune, or even scala (ooh, contentious)) - we can love a thing but understand that its time has been and gone. We can mourn what could have been, but there is no world in which Amiga will become a significant force again. Similarly, there is no world in which perl will gain significant marketshare again.
Futures, Promises, async, classes
Just use typescript