Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

Post reply on HN
Print view View original

551–560 of 573 posts

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

#551

Post by notyourday »

ricardobeat wrote: post #402
gbacon wrote: post #394

Earlier 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}

> print "[", +( join '', map { "-> $_" } @$_ ), "]" for @{$ref}

Because computers are so slow, memory is so limited and disk space is so expensive the programmer absolutely had to write it in a single line in the most convoluted way possible? Yeah, that's definitely a language fault.

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

#552

Post by kbenson »

gbacon wrote: post #485
amirkdv wrote: post #475

Earlier quoted context omitted.

I'm not the original comment author, neither am I fluent in Perl. But I suspect they meant nested hashes and not a hash whose values are arrays of arrays. As you point out, the latter is trivial. To be clear, even a nested hash is all well as long as the depth and the keys are literals (as in your example). It is when keys are dynamic that things get unruly. And god forbid if the _depth_ of nesting is dynamic. All of…

%nested = (foo => { bar => { baz => "quux" } }); Access the leaf with $nested->{foo}{bar}{baz} If the keys are in variables, it becomes $nested->{$x}{$y}{$z} For dynamic depth, do you have a specific use case in mind? If I have a tree, I’m probably going to search it rather than using a hardcoded path.

This is why we use strict! The extra arrow is unneeded, as you're working on the actual hash, not a reference to the hash. This is a compiler error with use strict though, so it's not something you would generally be bitten with when writing real code, just internet comments. :)

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

#553

Post by throwaway373438 »

7thaccount wrote: post #533
throwaway373438 wrote: post #486

Earlier quoted context omitted.

No, his estimates look pretty accurate to me. I've also done a fair bit of both Perl and Python (including working with the internals in C). Perl is significantly faster than Python for many types of common string manipulation tasks. They're both fast, sure, but Perl has some key optimizations.

For maybe some regex tasks sure, but there are also plenty of Python operations that are significantly faster than Perl, not to even mention all the data science stuff. I might have misunderstood the comment as evaluating the language on one thing doesn't capture a broad/general spectrum of usefulness.

Every language in this category will have bindings to domain specific high performance modules. This is part of why performance doesn't matter all that much - we can always push hot operations into another language.

Perl generally outperforms python in core language features.

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

#554

Post by tolger »

lizmat wrote: post #332
tolger wrote: post #310

This is great news! I was really excited about Perl 6, until I realized it was a different language, and it never quite jelled into a usable thing. So I kept using Perl 5. I write mostly modern Perl code, so this is exactly what I wanted. I learned Perl back in the late 90's when it was the best way to do web programming. As a C programmer, it was a breath of fresh air. It was a higher-level C for me and I used it fo…

No idea when it was the last time you tried jelling. But Raku is very much a usable thing nowadays and is used in production: https://raku.org

That's good to know. I will definitely check it out. Thanks!

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

#555

Post by gbacon »

kbenson wrote: post #552
gbacon wrote: post #485

Earlier quoted context omitted.

%nested = (foo => { bar => { baz => "quux" } }); Access the leaf with $nested->{foo}{bar}{baz} If the keys are in variables, it becomes $nested->{$x}{$y}{$z} For dynamic depth, do you have a specific use case in mind? If I have a tree, I’m probably going to search it rather than using a hardcoded path.

This is why we use strict! The extra arrow is unneeded, as you're working on the actual hash, not a reference to the hash. This is a compiler error with use strict though, so it's not something you would generally be bitten with when writing real code, just internet comments. :)

Whoops, good catch! I had references on the brain. For completeness, that makes it either

    $nested{$x}{$y}{$z}
or after initializing with curly brackets rather than parentheses to construct a new reference to an anonymous hash

    $nested = { … };
and then use the arrow to dereference as in the grandparent.

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

#556

Post by hpcjoe »

7thaccount wrote: post #454
proverbialbunny wrote: post #428

Earlier quoted context omitted.

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,…

I don't think your performance numbers are very accurate. I've done a bit of Perl and a lot of Python and they're fairly comparable in most cases. Python is lightning fast for a lot of scripting tasks and I generally use very few libraries for day to day tasks because the Python stdlib is so good. Unless you're doing something really simple with Perl command line switches that operate over an entire file, I'd bet Per…

No, the numbers are pretty accurate. In most of the cases I've run into, Perl is faster than Python for its operations. Some trivial examples[1] showed up on HN a few weeks ago, about how this person "optimized" python, by eventually replacing python with C.

As for the nested complex data structures, Perl's been doing that forever (e.g. since 5.x started). And its trivial to use.

That's one of the nicer aspects of Perl. Things you think should work, often, just do. And work the way you want them to. It's not perfect. It is very, very good though.

[1] https://scalability.org/2020/05/on-optimizing-scripting-lang...

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

#557

Post by hpcjoe »

7thaccount wrote: post #533
throwaway373438 wrote: post #486

Earlier quoted context omitted.

No, his estimates look pretty accurate to me. I've also done a fair bit of both Perl and Python (including working with the internals in C). Perl is significantly faster than Python for many types of common string manipulation tasks. They're both fast, sure, but Perl has some key optimizations.

For maybe some regex tasks sure, but there are also plenty of Python operations that are significantly faster than Perl, not to even mention all the data science stuff. I might have misunderstood the comment as evaluating the language on one thing doesn't capture a broad/general spectrum of usefulness.

Any data to back up this claim? My experience in dealing with large numbers of files, huge data sets, is that Perl generally roars, while python lags. I converted a python code to Perl associated with some recent work, and got a good ~2.5x overall improvement. It varied a bit as a function of the input, but generally Perl is superior in performance. Some areas Python is better, but not many.

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

#558

Post by lizmat »

cutler wrote: post #548
lizmat wrote: post #524

Earlier quoted context omitted.

Slow is in the eye of the beholder. Sure, for some applications, Perl blows Raku out of the water. Add in some Moose, and the situation is not so different. YMMV.

On my 4-core i7 Macbook Pro parsing a 20Mb log file with a regex takes 9.4 times longer with Raku than Perl5. That's unacceptable. Adding Moose to Perl5 reduces the differential to 7.1 which is still huge.

Do you have a gist of your code and a representative sample of the log file you're parsing?

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

#559

Post by 7thaccount »

throwaway373438 wrote: post #553
7thaccount wrote: post #533

Earlier quoted context omitted.

For maybe some regex tasks sure, but there are also plenty of Python operations that are significantly faster than Perl, not to even mention all the data science stuff. I might have misunderstood the comment as evaluating the language on one thing doesn't capture a broad/general spectrum of usefulness.

Every language in this category will have bindings to domain specific high performance modules. This is part of why performance doesn't matter all that much - we can always push hot operations into another language. Perl generally outperforms python in core language features.

The benchmarks shown elsewhere here tend to disagree with that. I think at one point that was more true than it is now. Overall though they seem to be comparable enough to where it probably doesn't matter.

Also, the bindings have to exist which they don't with Perl for a lot of scientific uses (PDL is not a substitute for Numpy/SciPy/Pandas).

Don't get me wrong. I own at least 12 Perl books and have reviewed some of the latest Perl 6 (Raku) books and really really like Raku. There's not much wrong with Perl in my book (certainly not what most people claim). I've reached for it a few times at work and found it to be fairly pleasant to use. My biggest complaints about building complex data structures in Perl (yes it's much easier than C, but still complicated if you're coming from Python) and having to remember when something is "$" that in my mind should be "@" have all been fixed by Raku.

I just wanted to point out that your views about it being much faster across the board don't seem to be correct.

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

#560

Post by kbenson »

py_or_dy wrote: post #406
deckard1 wrote: post #383

Earlier quoted context omitted.

> perl has been the same since 2002 if you ignore perl 6 then you might as well ignore python 3. And even still, python 2 is dead. There are only a handful of languages as well maintained as Perl 5. https://en.wikipedia.org/wiki/Perl_5_version_history Perl maintains strict backwards compatibility. I can run code that was written decades ago. I really am curious what features you think Perl 5 lacks. > Another issue is…

> Perl maintains strict backwards compatibility. I can run code that was written decades ago. I used to spout that off too, but I now think it is just a myth. When the leader/creator of the language abandons it and it sits there stagnate for years, what other "feature" can you advertise? I know, "strict compatibility"! I saw it as a feature as well and even used it as an excuse to not learn python. But even worse it…

> Breaking compatibility and refactoring is a sign of health, not death!

That is entirely dependent on what type of project it is, and what it's used for. Software that is not getting new features added and expected to work as it was and maybe get the occasional bug fix has no need for refactoring, and refactoring is almost definitely going to be detrimental before it possibly yields benefits.

A simple example of this is core Unix utilities, firmware, etc. When the scope is kept small, and the engineering is done well, those just work, and are expected to keep working. People aren't clamoring to refactor cp and mv. It is harder to keep these constraints sane as the code and project increases in size though.

Now, the ability to somewhat safely refactor is a sign of health, because it means there's high understanding of the scope of the code/project, and well known ways to test. That's a far cry from actually doing so, and I think you would be hard pressed to find a project that was undergoing a major refactor and breaking compatibility that I would look at and say "oh, they must be so healthy, because that's what healthy projects do, break backwards compatibility and refactor." The only reason to actually take on those tasks is because you have problems you think can't be fixes without them, which is not an indicator of healthiness.

> The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".

Just because your experience is web apps doesn't mean that's all there is. Do user facing applications that process user input need a lot of updates to make sure they stay in-line with security needs? Yes. Is all software user facing? Does all software need to support something as complex as a browser? No. Different classes of software have different classes of requirements. Does "it will still run on a new interpreter 20 years later" sound interesting to someone doing web development? Probably not. Does it sound interesting to people running system software, that often pay hundreds of dollars per system just so they can run an OS that back-patches security problems so they have a stable running environment with minimal change for 5+ years at a time? Hell yes it does.

But that's okay, you want current, modern Perl web apps? Use Mojolicious. It has a well defined deprecation policy, and you're forced to update your code if you stay up to date with it and be secure, just as you would expect from any Modern web app that takes things seriously (because some problems well be architectural, and may require user changes to fully accommodate).

> But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world.

I'm not really sure what this has to do with Perl or Python. This is security, systems, and web best practices, and the language is irrelevant to the example. You shouldn't need to go to /r/python to tell your boss that storing a password in plain text and with bad requirements for users is bad practice. Sure, it might work, but I think it's more indicative of cargo-cult behavior, and spreading it. If I'm building a Perl app, or a Haskell app, or Rust app, I should be able to pop into /r/python or anywhere else I expect someone might be around with experience, ask about best practices, and get a response that is not couched in "we just do X in flak/django whatever". If someone isn't explaining why storing passwords in plain text is bad, then they aren't really giving a good answer.

> The same goes for the perl mailing lists and irc. Its all dead.

That's now my experience. I don't bother going to IRC often, but I get helped whenever I do. IRC still seems to be the preferred medium for Perl devs to congregate and communicate. Not much else I can say about this, you didn't really provide much info other than it didn't help you and there's nobody there to help you, and my experience is different.

Post reply on HN