Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

371–380 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#371

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

There are a lot of modules and historical code stuck in old paradigms, but those are useful in their own way for backwards compatibility. There's also newer Perl modules that see heavy use, like Type::Tiny, Mojolicious, etc. We do a lot of internal web-apps with Mojolicious at work, and our larger ones make heavy uses of websockets, async code, and in some cases Vue.js.

> The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014.

The popular ORMs for Perl (DBIx::Class, etc) are fairly DB agnostic, so work with Postgres, MySQL, MSSQL, Oracle, etc. You aren't likely to see specific features for one DB in them because of that. What you gain is a consistent and advanced interface for interacting with databases which is mostly the same regardless of the back-end for that project.

There are newer, specialized modules such as Pg or Mojo::Pg to give you specific Postgres capabilities or to enable a more asynchronous model if that's what you're looking for.

Sounds like you had some bad experiences, and that sucks. Nobody will blame you for "jumping ship", but I would suggest you not think of it necessarily like that. You learn and code what you have to for work, and you learn and you code what you feel like or you think gives the most benefit personally. Those naturally change over time for a lot of people, and sometimes they are the same sets of items, and sometimes they aren't. If you ever want to play around with Perl again, even just for fun, it's there for you. It's not going anywhere. Perl doesn't have to be the language you write to make a living, or even the first one you reach for for certain projects, but it might still be a good option for some things, and there's no reason to discount it entirely if you still know how to use it and can find a use case for it.

For example, even if I stop using Perl primarily for development, I'm pretty sure it's going to be the tool I reach for when I need to quickly process some data for the foreseeable future. Just the fact I can pull in anything from CPAN to supplement a one-liner (or a one liner I've copied into a file and formatted to turn into a small script) makes it invaluable over just awk and sed.

Re: Perl 7 is going to be Perl 5.32, mostly

#372
post #314
post #130

Much as people complain about Perl, it is the language which I use when I want to have something which will run 10-20 years from now. I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time ( https://github.com/jwr/ccheck ). Very happy to see a path forward for Perl 5.32.

Interesting, I've been moving away from Perl and Python and towards Rust precisely because I'm afraid of bitrot. Perl the language is stable as fuck and takes back-compat extremely seriously. The problem for me was the library ecosystem: Cpan makes it tedious to pin/vendor dependencies, and installs dependencies globally by default.

You might want to look at Carton and cpanfiles as a way of managing dependencies. You can also get really ancient stuff off BackPAN, should your dependencies disappear from CPAN proper.

https://metacpan.org/pod/Carton#Tracking-the-dependencies

http://backpan.perl.org/authors/id/

Re: Perl 7 is going to be Perl 5.32, mostly

#373

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

> it is not the notorious "write only" language that many troll it to be I dispute that. I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics. There is a reason it has that reputation. Even writing it isn’t easy. I can describe the Python syntax after years of not using it. Perl? No way I remember it.

Understood. I stated that to say my problems with perl is not the language itself. To say it is the "community" is not right either. But basically "what is left of the community" is the issue. Languages like python, ruby, perl, etc are only good (if you want to freelance and make money at least) at being a "skin" around a database. That also entails a knowledge of frontend frameworks and workflows as well. Yet the words "database", "javascript", or "webpack" are very rarely mentioned at any of the perl conferences in the last 5 years! In the case of webpack, that's probably never been mentioned.

Re: Perl 7 is going to be Perl 5.32, mostly

#374

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

I loved Perl back in at the turn of the millennia. My first data science equivalent projects were in Perl. To this day I can not find anything quicker to prototype in. Python is slow in comparison. Perl is great for quickly hacking something together for R&D purposes. Also, if you need to write something custom, Perl runs so much faster than Python and R. I, like many people, stopped using Perl beyond a quick script…

Do you mean faster to write, or faster to run, or the combination of both?

Re: Perl 7 is going to be Perl 5.32, mostly

#375
post #286
post #257

Earlier quoted context omitted.

Whatever happened to the neophyte raising him/herself up to level of the master? Programming seems to be the only profession in which the beginner is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? If you want to grok Perl learn…

> Programming seems to be the only profession in which the neophyte is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? Yes. Yes I can[1] [1]: https://how-to-play-electric-guitar.net/tab-symbols.html The problem isn't merely that…

> programmers are people too

Are we really?

Re: Perl 7 is going to be Perl 5.32, mostly

#376
This article touches on something that I really enjoyed about (the early days) of Perl 5, and I think it may body well for the future of the language.

You could write Perl 5 like it was just a better Perl 4. All of the craziness with modules and references was hidden to you if you wanted to write a Perl 4-esque script that needed to talk to a database or do something else that you could find a module in for in CPAN.

The people would wrote those modules, God help them, I don't know how they managed to write the executable line noise that was in the source, but I didn't care. I could get my job done with a few simple `use` statements.

Re: Perl 7 is going to be Perl 5.32, mostly

#377
post #100
post #52

Earlier quoted context omitted.

On my 4-core i7 Macbook Pro: time ./startup_time.pl 0.016s time ./startup_time.py 0.295s Parsing a 20Mb log file with a regex: time ./parse_log.pl 0.683s time ./parse_log.py 1.534s For which metric are you claiming Perl is slower than Python?

Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.

I took some similar benchmarks recently: https://code.ivysaur.me/interpreter-binary-perf

Perl5 won the dec2bin benchmark.

The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.

Re: Perl 7 is going to be Perl 5.32, mostly

#378

Earlier quoted context omitted.

Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.

There are a couple of points in there: 1. You can use virtually any language to write clean code Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really…

In my 30 years (yes) working with Perl (4->5.32), I have never, once, used wantarray. Perl does not lend itself to bad code. Bad coders, people whom cannot use or articulate good practice in coding or documentation, lend themselves to write bad code, in any language.

I used it for automation of my calculations in grad school. For data analysis. For monitoring.

In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.

Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].

For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].

Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.

I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.

[1] https://community.hpe.com/t5/advantage-ex/how-my-supercomput...

[2] https://community.hpe.com/t5/advantage-ex/the-story-of-how-i...

[3] https://scalability.org/2020/04/fun-and-topical-hpc-project-...

Re: Perl 7 is going to be Perl 5.32, mostly

#379
post #82

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

Perl was a great fun scripting language back in the day of CGI and "webmaster@". It died a noble, honorable death. RIP.

[deleted]

Re: Perl 7 is going to be Perl 5.32, mostly

#380
post #232

Developers in their forties wrote Perl. Developers in their thirties replaced Perl. Developers in their twenties say “What’s Perl?”

Developers in their teens say: Wow, Raku! https://raku.org (formerly known as Perl 6)

I'm in my late 40s and say "Wow, Raku!".

I haven't used it for anything work related yet, but working with it is mind expanding and makes me a better programmer in whatever environment I work in.

The type system, multiple dispatch, literate programming support, and command line scripting features are simply amazing.

Post reply on HN