7 ms·
I once loved Perl, it was the first language I learned, but reading through the comments and link I don’t see how you turn it into a modern, well loved and well
by j4yav 6y ago
I once loved Perl, it was the first language I learned, but reading through the comments and link I don’t see how you turn it into a modern, well loved and well used language (or even stop the decline) through small improvements but no grand vision, or by stepping away from the past in a meaningful and painful way.
I wish them nothing but success, and sincerely hope their plan works, but I personally didn’t read anything there that made me think “oh wow, I’ll have to give Perl a try again when they deliver on their vision.”
- dash2 6y agoI wonder if they got burned by Perl 6/Raku. That had tons of new features but took so long to deliver that it became a burden. Anyway, I think you're right: they have to be more proactive than just going for "feature parity with a modern language".
- yabadubakta 6y agoI recommend going to https://raku.org/ https://raku.org/ and reading up on the language because Raku actually has features “modern languages” do not. E.G. the grammars.
- thatwasunusual 6y ago> I wonder if they got burned by Perl 6/Raku. I have the same feeling. I've been programming Perl since mid 90s, and I was - as many others - hyped when Perl 6 was announced early 2000s. 20 years later, it's just different programming language in my eyes; I won't spend any time on it, because if I need Perl, Perl 5.x will do just fine. Unfortunately, because of Perl 6/Parrot/Raku, or what the current name is, I think it made many developers get off the Perl train. There are lots of good frameworks for Perl that makes it super-easy to get something up and running really quickly; * Mojolicious (and its multitude of plugins, Minion etc.) * DBIx::Class (not pretty, but still just works) * Moose/Mouse (for decent OOP) * JSON::Validator (and friends, for mocking and validating) The list goes on, but this is the "out of the box"-stuff for me to get up and running with something, if not just a prototype of something.
- Macha 6y agoWasn't Perl 6 itself a reaction to the fact that a lot of developers already leaving for PHP in the web space and Python in the "I need something like a shell script, but need/want a real programming language".
- thatwasunusual 6y agoI honestly don't remember. Nor do I care anymore. :)
- bmn__ 6y agoNo. http://strangelyconsistent.org/blog/happy-10th-anniversary-perl-6 http://strangelyconsistent.org/blog/happy-10th-anniversary-p...
- raiph 6y agoAs Jon Orwant (supposedly) said in 2000 (quoting from the article you linked): > we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things
- sigzero 6y agoThere is no "wonder". They did.
- G3rn0ti 6y agoYeah, Perl 6 created a lot of confusion especially inside the Perl 5 community. But, in the end, they figured it all out: Perl 5 lives on and Perl 6 got out of its way by renaming itself to Raku. And, for the record: Raku itself is a gem of a language, I believe. A pretty solid OO system, optional typing, powerful language constructs, stellar Unicode support and somehow it is still staying true to Perl's rather pragmatic and, if I may say so, libertarian approach to software developing. I personally love raku's "grammars" most because they render writing parsers a routine job, it's amazing and no other programming language provides such a feature. If you're interested I strongly suggest you to check out Brian D Foy's book on Raku: https://www.oreilly.com/library/view/learning-perl-6/9781491977675 https://www.oreilly.com/library/view/learning-perl-6/9781491....
- vram22 6y agoHow about the reported Perl6 / Raku speed issues? Saying "reported" because I have not done an in-depth study if they exist, just read about it briefly somewhere (and a while ago, may a year or so). If they did/do exist, was/is anything being done about them? Asking because I, for one, found both Perl 5 and 6 interesting, and the language features of both, somewhat unusual and powerful.
- G3rn0ti 6y agoI think Raku is still quite a bit slower. But I am not up-to-date with the latest state. However, this is "just" a matter of optimization of the interpreter over time. It's just that Perl 5's interpreter had a head start of more than 25 years.
- vram22 6y agoYes, that is possible. Java was dead slow early on (I first used it soon after it came out, and pioneered use of servlets in my company at the time), but after Sun's management threw millions of dollars and high-end tech people at the problem, it got fast enough for many uses in a few years, what with the Hotspot VM and JIT tech and so on.
- Stranger43 6y agoI don't remember anyone paying much attention to perl6 before long after perl had peaked. It was for a while seen as an potential savior for perl but that faded too. It was more about PHP, Ruby and Python entering the stage and diluting the market for scripting languages by each offering something special that one set of users really wanted weather it be an easier deployment path better standard libraries or a more beginner friendly community.
- petepete 6y agoI did a fair amount of Perl just over a decade ago but can't really see any situation where I'd reach for it over Ruby now. Ruby has Perl's text manipulation goodness with a saner syntax.
- blacktriangle 6y agoPerformance. Perl was a legit tool in bioinformatics due to its insane text parsing performance. Ruby performance is absolute garbage.
- yabadubakta 6y agoAnd ubiquity: there’s a Perl for almost all systems
- PLenz 6y agoI still do my NLP preprocessing in perl for this exact reason
- phone8675309 6y agoI learned Perl in the mid 2000s because I was working with a company that took text (and sometimes spreadsheet) dumps of public records data and processed them into a database. The entire ETL pipeline was a set of Perl scripts, and, as far as I know, that system is still running. The Perl iteration was actually the second iteration of that system - the first iteration was a set of C programs and shell scripts that were replaced over time. The rich ecosystem of tested Perl modules for file formats along with the testing frameworks made coping with change bearable - not enjoyable, but bearable.
- yoz-y 6y agoDo they have to enter the modern world and compete with the modern languages? Personally, I’d like them to focus on shell scripting and tool making. (But that’s what I use Perl for, so of course I’d say that)
- j4yav 6y agoThey don’t have to, but it seems to be their stated goal.
- b2gills 6y agoIronically making it more modern may make things like shell scripting easier. Let's say that Perl gets a real type system, and reflection capabilities. Then I can see something like this come to exist: use v7; use GetOpt::MAIN; sub MAIN ( str $name, int $count ) { say $name for 1..$count }
- wpietri 6y agoI wrote a ton of Perl as well, but that stopped long ago. In the meantime I've learned a number of languages, Python and Ruby included. Maybe what they're doing is enough to slow down the decay in terms of user base. But I'd be shocked if it reversed it either by bringing old Perl users back or getting new ones. Of course, it could just be that this is an internally focused text. Maybe there's some other document that explains a product vision that says, "Perl will be better at X,Y, and Z for groups A, B, and C"?
- cestith 6y agoThis document is mostly discussing how they can deliver on a product vision without breaking existing code too badly. The product vision would be a different document of which features to add and why.
- wpietri 6y agoOh, sure. But does that different document exist?
- bmn__ 6y agomaybe https://youtu.be/6wPMh-3qYJM?t=3837 https://youtu.be/6wPMh-3qYJM?t=3837 (5:47 - 1:03:52) (meanwhile obsolete)
- cestith 6y agoExcellent question. I think a big part of the customer story is eventually getting a standardized object model like Corinna into the core language. I do know a lot of objections to Perl have come from the bare-bones built-in objects and the dozen or so ways to build on those using CPAN modules. Getting signatures in rather than the older function prototypes is another. I don't know that there is a unified vision for what future Perl will be yet, other than something that surprises people coming from other languages a lot less yet remains Perl.
- wpietri 6y ago
- fangorn 6y agoI liked writing Perl a lot, but when it came to reading, let alone fixing, other people's Perl, it was always a bit of a nightmare. That's one of the main reasons I was reasonably happy to move away from it - nobody seemed to heed "Just because you can, doesn't mean you should" mantra. Sure you can write good Perl, and I always did my best in that area, but it was not the reality for most Perl programs out there. CPAN also turned to a bit of a mess at some point, and in general dependency management was non existent, really. Containers could help alleviate this pain now, to an extent. Still, it would need to seriously improve to lay any claims to being able to write modern stuff in Perl.
- forgotmypw17 6y agoI use almost no third-party modules and write largely what I call "PHP style" Perl, so mostly $variable = SomeFunction($someOtherVariable); I've had no issues with reading my own code, and others are able to follow along as well. I admit that, because of its poetry-enabling flexibility, in terms of readability and maintainability foot-shooting, Perl is like an AK-47 with a full clip and no safety.
- philote 6y agoCPAN is great, but also horrible. There are so many packages that do the same thing, and it was often hard for me to know which to pick. Want OO? Use Moose, or Moo, or Mouse or whatever else. Then hope that the one you picked will continue to be maintained. I resisted moving to Python for a long time, but when I finally did it was a bit refreshing to have more packages built into the language so I didn't have to make so many choices on what 3rd-party libraries to install. Perl will always have a special place in my heart though. As far as reading code goes, Perl could be particularly messy, but I've seen some very hard to read Python code as well. And Javascript... I still don't get why people want to use it server-side. But all these languages have tooling that helps make sure code is at least formatted correctly, and follows some sort of best practices. I think one of the hardest parts of reading Perl, to me, was that it wasn't always clear what package a particular function or class was imported from.
- thatwasunusual 6y ago
- forgotmypw17 6y agoIt is already modern. The Perl community has boldly remained committed to compatibility over chasing the shiny and breaking shit, unlike many others (coughphpcough), which is why I chose Perl for a new project a couple years ago. I don't WANT so-called modernization. I want my program to remain working without having to change. it
- klibertp 6y ago> I want my program to remain working without having to change. it Can't you bundle the interpreter, possibly stripped down and compiled as a static binary, along with your program? But yes, strict backward compatibility, while having many downsides, provides a lot of value, too. The trade-off is situation and project dependent, and it's good to have both kinds of platforms: ones solid as a rock and moving slowly, and ones moving fast and breaking things.
- jrsj 6y agoThis will work for awhile until you stop receiving security updates and have to adapt to breaking changes to do so.
- forgotmypw17 6y agoBundling the interpreter would interfere significantly with being able to download and run from source.
- bmn__ 6y agohttps://metacpan.org/pod/pp https://metacpan.org/pod/pp https://metacpan.org/pod/staticperl https://metacpan.org/pod/staticperl https://metacpan.org/pod/perlcc https://metacpan.org/pod/perlcc But that's the worst way to deploy a program.