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…
> A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot th…
Perl 7 is going to be Perl 5.32, mostly
441–450 of 573 posts
Re: Perl 7 is going to be Perl 5.32, mostly
#442Earlier quoted context omitted.
Do you mean faster to write, or faster to run, or the combination of both?
Both. Perl is around 20x slower than C for common tasks, while Python is around 133x slower than C for common tasks like looping, depending on what you're doing of course. Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python,…
Please stop perpetuating this myth. It really depends how you write it. Perl isn't going to do the tidying up for you, you'll have to properly structure the code yourself. If you still write Perl code like it’s 1991 then maybe itcs not maintainable. I work on a largeish Perl code base and I can assure you it's quite maintainable, moreso than most Js that people install via npm as we speak.
Re: Perl 7 is going to be Perl 5.32, mostly
#443Earlier quoted context omitted.
I feel you. I'm currently at a startup that, somewhat by accident, ended up writing their backend in PHP. Modern PHP is actually fine; it's largely avoided the issues perl has; adoption of the latest versions is quite high, and it's...fine. Not the best, not the worst, broadly comparable to other languages, and a far, far, far cry from what most people may think of when they hear "PHP". My last job used Node, the one…
I heard the "PHP is becoming like Java" argument in 2005 when PHP 5 came out. I'm surprised to hear it's still a thing. Funny enough I heard the same thing about JavaScript about 5 years ago when ES6 came out.
Ha, if anything I think it's intensified. A current focus is on adding support for annotations (aka attributes from C#), which will be strictly opt-in and replace an ugly pattern currently widely used in PHP land of using docblocks to store them and then parsing them out at run time. "Hey, people keep storing these things in comments, lots of other languages have them as a real feature, let's do the same and make things saner and more efficient."
Simple right? But no, it's actually been quite controversial, and by no means just due to bikeshedding about syntax. Here's a selection of quotes (all highly upvoted) from a recent announcement on the PHP subreddit announcing that the feature has been accepted for PHP 8.0 and linking to a detailed document explaining the use case in painful detail:
"What problem is this trying to solve? I don’t think I’m a fan." "Not sure if I'm a fan. [...] IMO it got way out of hand in Java." "How about no? What does it solve that you can not already program with PHP. If other languages are any indication, its one of those changes that WILL get misused from here to high end." "yeah no thx"
Re: Perl 7 is going to be Perl 5.32, mostly
#444Earlier quoted context omitted.
> 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. For example?
A classic (hope I didn't get it wrong): print "[", +( join '', map { "-> $_" } @$_ ), "]" for @{$ref}
Re: Perl 7 is going to be Perl 5.32, mostly
#445Earlier quoted context omitted.
Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers. You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way. So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programme…
> and it’s hard to impossible to find Perl programmers Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon. That is: a senior programmer should ha…
Those are all pretty basic Algol-family languages (at least if we're talking vaguely modern Javascript). If you were thrown in to J or Forth or Erlang you might have a different experience.
Re: Perl 7 is going to be Perl 5.32, mostly
#446They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack. Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again: Traceback (most recent call last): File "/usr/local/bin/pip", line 11, in sys.exit(main()) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main command = create_command(cmd_name,…
Re: Perl 7 is going to be Perl 5.32, mostly
#447Earlier quoted context omitted.
Honestly that's more than most I think. I've written tens of thousands of lines of perl professionally and I generally share the same opinion.
I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ al…
Re: Perl 7 is going to be Perl 5.32, mostly
#448Earlier quoted context omitted.
Both I would guess. Perl in serial is already faster to run than Python, and as soon as you start using threads Perl blows Python straight out of the water. The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs. Writing faster is debateable, but Perl has tons of niceties like embedded regex syntax, string interpolation, one-line…
I've been writing Python for a good while now and I haven't seen too many issues between minor versions. As for major versions...well...there's only been one significant change in this area (2 to 3) so I feel like maybe you're hyperbolizing a little :-)
So it happened once but it took up about 25% of the last 20 years.
Re: Perl 7 is going to be Perl 5.32, mostly
#449They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
Re: Perl 7 is going to be Perl 5.32, mostly
#450Earlier quoted context omitted.
I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ al…
I think a useful concept is that a project will have a "discipline budget", just like the "language strangeness budget". Yes, if you're careful with your self-restraint and code reviews, you can write good, clean, maintainable code in a language that doesn't give you a lot of support for that. But if you do that then you're expending your limited supply of discipline, and will have less to spend on other aspects of t…